تتوفر ميزة Runway Enhance Frame Rate على Dev API: من 24 إلى 120 إطارًا في الثانية، مع تضمين NTSC.

أطلقت Runway نموذجًا جديدًا لاستيفاء الإطارات على واجهة برمجة التطبيقات الخاصة بالمطورين لديها في 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 ثانية من الإدخال لكل مهمة، ويُحتسب بسعر رصيد واحد لكل ثانيتين.

سطر الفوترة هذا هو المفاجأة الثانية. عادةً ما يُسعَّر استيفاء الإطارات حسب المخرجات — يفرض Magnific Video Upscaler الخاص بـ Runway على نفس نقطة النهاية تلك رسومًا قدرها 0.7 من الأرصدة لكل إطار مُخرَج عند 720p/1K — مما يعني أن تحويل 24 إطارًا في الثانية إلى 120 إطارًا في الثانية يكلف خمسة أضعاف ما يكلفه تحويل 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"، ويُعاد إليك معرّف مهمة، ثم تستعلم دوريًا عن النتيجة. ولأنها تشترك في نقطة نهاية مع أداة رفع الدقة الخاصة بـ Runway، فإن خط أنابيب يتواصل بالفعل مع /v1/video_upscale يحتاج إلى تغيير معامل بدلاً من تكامل جديد.

يسرد سجل تغييرات Runway ما يلي بوصفه المواصفات الحالية المعلنة من المورّد. لم يتم التحقق من أيٍّ منه بشكل مستقل — فلا يوجد اختبار مرجعي من طرف ثالث لهذا النموذج، وعمره يوم واحد وقت كتابة هذه السطور.

• المعدلات المستهدفة — 24، 25، 30، 48، 50، 60 و120 إطارًا في الثانية، بالإضافة إلى 23.98 و29.97 و59.94 إطارًا في الثانية (المكتوبة في API باسم 23_98 و29_97 و59_94)

• حد الإدخال — 300 ثانية لكل مهمة

• السعر — رصيد واحد لكل ثانيتين من الإدخال؛ تكلفة رصيد Runway API هي 0.01 دولار للرصيد الواحد

• الوصول — POST /v1/video_upscale مع النموذج: "enhance_frame_rate"، على Runway Dev

• سابقة لدى Runway — كان نوع مهمة frame_interpolation_v1 موجودًا ضمن إصدار API بتاريخ 2024-11-06؛ وأداة Frame Interpolation المستقلة على الويب مهمَلة

• تقييم مستقل — لم يُنشر أي منها

سلّم معدل الإطارات، ولماذا يُعد 23.98 هو العنوان الحقيقي

كل أداة استيفاء موجّهة للمستهلك تقدّم معدلات صحيحة. العمود المثير للاهتمام هنا هو العمود الكسري، لأن المعدلات الكسرية هي ما تنص عليه مواصفات التسليم فعلاً:

• 23.98 (23.976) — معدل أفلام NTSC. كل ماستر سينمائي وماستر بث تقريبًا، والمعدل الذي أُعدّت عليه أقراص DVD وBlu-ray.

• 24 — معدل العرض الحقيقي للأفلام، ولا يزال يُستخدم في DCP والعديد من المخرجات الخاصة بالمهرجانات.

• 25 — مناطق PAL وEBU: المملكة المتحدة، ومعظم أوروبا، وأستراليا، وأجزاء كبيرة من آسيا وأفريقيا.

• 29.97 — بث NTSC، النظير الكسري للـ 30.

• 30 — معدل صحيح لتسجيل الشاشة ولقطات الويب والألعاب.

• 48 — سينما بمعدل إطارات عالٍ (المعدل الذي صُوّرت وعُرضت به أفلام الهوبيت).

• 50 — معدل إطارات عالٍ بنظام PAL، أي 2× 25 بالضبط.

• 59.94 — معدل إطارات عالٍ بتقنية NTSC، وهو معدل البث 60 هرتز في الولايات المتحدة واليابان.

• 60 — عدد صحيح 60 هرتز، الهدف الشائع للتشغيل السلس على الويب.

• 120 — الحركة البطيئة، وعرض بمعدل تحديث عالٍ.

تبدو الفجوة بين 24 و23.976 ضئيلة، لكنها ليست كذلك. خلال ساعة واحدة من مدة التشغيل، يتباعد المعدلان بنحو 3.6 ثانية. إذا أدخلت نسخة رئيسية بمعدل 24.000 في سلسلة تسليم بمعدل 23.98، فستحصل على انحراف في مزامنة الصوت وأخطاء في الإيقاع (الكادنس) سترسب في فحص الجودة الخاص بالبث — ولهذا كانت استوديوهات ما بعد الإنتاج تاريخيًا تنفذ خطوة مطابقة (كونفورم) منفصلة لإعادة أخذ عينات المعدلات، أو ترفض المهمة. الأداة التي تُصدر المعدل الكسري مباشرةً تحذف مرحلة من تلك السلسلة. هذا ادعاء أضيق نطاقًا وأكثر إثارة للملل بكثير من «120 fps»، وبالنسبة لأي شخص يسلّم إلى جهة بث، فهو السبب وراء الاهتمام.

المعدّلان المستهدفان 48 و120 هما ما ينبغي الشك فيه عمليًا. إن استيفاء مادة بمعدل 24 إطارًا في الثانية لرفعها إلى 120 إطارًا في الثانية يعني اختلاق أربعة إطارات مقابل كل إطار حقيقي، وعند الحركة السريعة أو الاحتجاب أو التمويه الحركي الشديد، تُنتج أدوات الاستيفاء على اختلاف أنواعها ظلالًا شبحية وتشوّهًا. لا تنشر Runway أي تحليل للعيوب، ولا أي مقارنة مع أي أداة استيفاء أخرى، ولا أي إرشادات جودة لكل لقطة على حدة — لذا فإن الموقف الصادق هو أن المواصفات تدعم 120، أما كيف يبدو 120 على لقطاتك فلم يُختبر.

كم تبلغ تكلفته، موضّحة خطوة بخطوة

الحساب سهل على نحو غير معتاد لأن الوحدة هي الثواني المُدخلة. بمعدل رصيد واحد لكل ثانيتين، و0.01 دولار لكل رصيد على واجهة برمجة تطبيقات المطورين الخاصة بـ Runway (مدفوعة مسبقًا، بحد أدنى 10 دولارات مقابل 1,000 رصيد):

• مقطع مدته 10 ثوانٍ، بأي معدل مستهدف — 5 أرصدة، حوالي 0.05 دولار

• مقطع مدته 30 ثانية — 15 رصيدًا، حوالي 0.15 دولار

• مقطع مدته 60 ثانية — 30 رصيدًا، حوالي $0.30

• مقطع مدته 5 دقائق، بحد أقصى 300 ثانية — 150 رصيدًا، حوالي 1.50 دولار

• مقطع مدته 90 ثانية، 24 → 25 إطارًا في الثانية — 45 رصيدًا، حوالي 0.45 دولار

• نفس المقطع البالغ 90 ثانية، 24 → 120 إطارًا في الثانية — 45 رصيدًا، نحو 0.45 دولار

هذان السطران الأخيران يمثلان حجة التسعير كاملة. في نموذج التسعير على أساس كل إطار ناتج، سيكون عدد إطارات المهمة الثانية 5 أضعاف، وبالتالي ستكون الفاتورة نحو 5 أضعاف. أما هنا فهي مجانية.

إن المقارنة مع الجار على نقطة النهاية نفسها تجعل الفكرة ملموسة. يفوتر 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 دولار. إذا أردت معدل إطارات أعلى وليس صورة أكبر، فإن الاستعانة بأداة رفع الدقة تكلف نحو أربعين ضعفًا. لاحظ أيضًا أن تفعيل ميزة fps boost الاختيارية في أداة رفع الدقة يغيّر عدد الإطارات الناتجة، وبالتالي يزيد تلك الفاتورة أكثر — وثائق أسعار Runway تقول ذلك صراحةً.

ملاحظة تحذيرية واحدة بشأن التكلفة تجدر الإشارة إليها: صفحة أسعار المطورين الخاصة بـ Runway هي المرجع المعتمد هنا، وليس هذا المقال، وقد ورد أن سعر الائتمان قيد المراجعة للتوجه نحو تسعير مخصص منذ أغسطس 2026. تحقق من البوابة قبل أن تخصص ميزانية لدفعة كبيرة.

سقف الـ300 ثانية، وكيفية التحايل عليه

كل مهمة محدودة بـ300 ثانية من الإدخال. وهذا سخي بالنسبة للقطة وقصير بالنسبة للريل، لذا أي شيء أطول يجب تقسيمه — وطريقة التقسيم تهم أكثر من الحد الأقصى نفسه.

اقطع عند حدود المشاهد، وليس وفق ساعة ثابتة. تستنتج أدوات الاستيفاء الحركة بين الإطارات المتجاورة؛ وعند القطع الحاد، لا توجد أي علاقة حركة على الإطلاق بين الإطار الأخير من اللقطة A والإطار الأول من اللقطة B، والنموذج الذي لا يكتشف القطع سينشئ بلا تردد تحولًا تدريجيًا بينهما. لا يوثّق سجل تغييرات Runway الكشف التلقائي عن المشاهد لهذا النموذج، لذا فإن الافتراض الآمن هو عدم وجوده. قسّم إلى مقاطع عند مواضع القطع، وطبّق الاستيفاء على كل مقطع، ثم أعد تجميعها على خط زمني بالمعدل الجديد.

هذه النصيحة ليست خاصة بـ Runway — فهي التحذير المعياري بشأن إعادة ضبط التوقيت بالذكاء الاصطناعي في كل مكان. وتطرح ورقة بحثية من SMPTE لعام 2025 حول ما بعد الإنتاج بمساعدة الذكاء الاصطناعي، تصف مسارًا لاستيفاء الإطارات محسّنًا بواسطة TensorRT لتحويلات مثل 23.976 → 25 و29.97 → 23.976، النقطة نفسها: يحتاج المحتوى المحوَّل بالإطارات إلى فواصل إطارية عند قطع المشاهد، وإلى ضبط الجودة (QC) بعد ذلك، وإلا فإن النموذج يهلوس عبر موضع الوصل. توقّع أن تحتاج التمريرة الأولى إلى استبدال يدوي للإطارات حول الانتقالات الصعبة.

أين يقع مقارنةً بالبدائل

ظل استيفاء الإطارات مشكلة شبه محلولة لبعض الوقت، في شكلين يبدو كلاهما مختلفًا عن هذا.

• حزم سطح المكتب — تُعدّ نماذج Apollo وChronos من Topaz Video AI النقطة المرجعية لإعادة التوقيت المركّزة على الجودة. ترخيص دائم، ووحدة معالجة الرسومات الخاصة بك، وبلا عدّاد لكل ثانية، وتمريرة ضبط تكافئ من يعرف ما ينظر إليه.

• مُولِّدات الإطارات البينية مفتوحة المصدر — RIFE ونماذج مشابهة، مُستضافة ذاتيًا، مجانية فعليًا على الهامش بمجرد امتلاكك للعتاد، وهي الأساس الذي بُنيت عليه معظم خطوط المعالجة المخصصة التي أنشأتها استوديوهات ما بعد الإنتاج بنفسها.

• Runway Enhance Frame Rate — لا حوسبة محلية، بل استدعاء API، وفوترة حسب كل ثانية مُدخلة، ومعدلات NTSC الكسرية التي طالما تركك الآخران لتتوافق معها يدويًا.

المقايضة واضحة. بالنسبة إلى لقطة لمرة واحدة على محطة عمل تملكها بالفعل، ستكون أداة استيفاء محلية أرخص وتمنحك أدوات تحكم لا تتيحها Runway. أما بالنسبة إلى مواد تصل ضمن مسار آلي، أو مصفوفة تسليمات يجب أن يخرج فيها المقطع نفسه بمعدل 23.98 لإقليم و25 لآخر، فإن واجهة API تعيد المعدل الكسري مباشرةً وتُلغي خطوة المطابقة — كما أن السعر لكل ثانية إدخال يعني أن الإخراج متعدد المعدلات لا يضيف أي تكلفة إضافية.

طبقة التوجيه المحيطة به

إعادة التوقيت مرحلة واحدة في خط معالجة توجد فيه خطوة نموذج لغوي في مكان قريب منه. قائمة اللقطات وملاحظات المطابقة، وتمريرة الترجمة والتعليقات التي يجب إعادة توقيتها وفق معدل الإطارات الجديد، والبيانات الوصفية لتسليم كل منطقة، وسجل فحص الجودة — كل ذلك عمل نصي، وهو الجزء من خط معالجة الفيديو الذي لا يضع له أحد ميزانية.

تعمل هذه الطبقة على مفتاح واحد عبر النماذج المئتين في كتالوج OrcaRouter، مع تمرير أسعار قوائم المزوّدين بهامش ربح 0% وتحويل تلقائي عند الفشل بين المزوّدين، بحيث يمكن تجربة نموذج أحدث أو أرخص على حركة مرور حية دون المخاطرة بمسار إنتاجي عليه. وللدقة في النطاق: Runway Enhance Frame Rate هو نموذج Runway Dev API، يُستدعى عبر نقطة نهاية Runway الخاصة، ولا يقدّمه OrcaRouter. ما نغطّيه هو كل ما يحيط به.

ما لم يُعرف بعد

لا شيء تقريبًا يتعلق بالجودة. عمر هذا النموذج نحو يوم واحد وقت كتابة هذا النص، وكل ما ورد أعلاه عن سلوكه يأتي من سجل التغييرات والإعلان الخاصين بـ Runway. وتحديدًا، غير مُتحقَّق منه:

• سلوك التشوهات عند الحركة السريعة، والانسداد، وضبابية الحركة، والمصادر منخفضة معدل البت — لا توجد اختبارات منشورة من أي جهة

• ما إذا كان يكتشف قطع المشاهد تلقائيًا، أو يمزج عبرها

• ما إذا كان الصوت يُمرَّر كما هو، أو يُعاد أخذ عيّنات منه، أو يُسقَط عند تغيّر معدل الإطارات

• كيف يمكن مقارنته من حيث الجودة بـ RIFE أو Apollo أو Chronos — لا توجد مقارنة مباشرة

• ما إذا كان سعر كل ثانية إدخال سيظل ثابتًا مع ارتفاع المعدل المستهدف، أم سيُعاد تصنيفه ضمن شريحة سعرية لاحقًا

تعامل مع معدّلي 120 fps و48 fps المستهدفين باعتبارهما ادعاءين فقط حتى تُمرّر لقطاتك الخاصة من خلالهما، وتحقق من طريقة التعامل مع القطع في أول مقطع ترسله.

من يجب أن يتحرك الآن؟

تحرّك الآن إذا كنت تسلّم وفق مواصفات البث أو مواصفات مناطق متعددة وتدفع حاليًا مقابل خطوة المطابقة (conform)، أو إذا كانت لقطاتك تمر بالفعل عبر مسار آلي يمكنه استيعاب استدعاء API إضافي، أو إذا كنت تريد حركة بطيئة من كاميرا لم تصوّر مطلقًا بسرعة عالية وتفضّل ألا تشغّل GPU.

انتظر إذا كنت تحتاج إلى أكثر من خمس دقائق في مهمة واحدة ولا يمكنك التقسيم عند مواضع القطع، وإذا كنت تحتاج أيضًا إلى رفع الدقة — أي أداة رفع الدقة، بأسعار لكل إطار — أو إذا كنت تملك بالفعل أداة توليد إطارات بينية سطح مكتب وهذه لقطة لمرة واحدة. وانتظر إذا كانت الجودة هي العامل الحاسم بدلًا من الراحة: لم ينشر أحد خارج Runway رقمًا، وأول مقارنة مستقلة هي الشيء الذي يستحق الانتظار.

النمط الجدير بالمراقبة هو ما إذا كانت Runway تواصل توسيع نقطة النهاية هذه نموذجًا تلو الآخر. فهي تحمل بالفعل أداة تحسين دقة إبداعية، والآن أداة إعادة ضبط التوقيت، وكلتاهما على POST /v1/video_upscale، وكلتاهما مسعّرة بوحدات مختلفة تمامًا. وبالنسبة لأي شخص يبني خطوط أنابيب التسليم، فإن الوحدة — الثواني المُدخلة بدلًا من الإطارات المُخرجة — هي الجزء الذي يستحق التصميم حوله.