لماذا انتقلنا من Remotion إلى HyperFrames لتوليد الفيديو البرمجي

يبدو بناء مسارات توليد الفيديو المؤتمتة اعتماداً على محركات المتصفح فكرة نظيفة نظرياً: مكوّنات React ترسم المشاهد، وقواعد CSS تدير الانتقالات، ومتصفح Chromium خفي بدون واجهة يرسل الإطارات إلى FFmpeg. قمنا بتشغيل مسار الإنتاج لدينا وفق هذه البنية لعدة أشهر عبر دفعات عديدة من الفيديوهات الداخلية وفيديوهات المشاريع.

في وقت سابق من هذا الأسبوع، أجرينا اختبارات أداء قياسية تجريبية على فيديو الإطلاق الرئيسي ومدته 38.8 ثانية. وأجبرتنا النتائج على إجراء تحول معماري فوري.

استغرق مسار Remotion نحو 74.2 ثانية لإنتاج ملف MP4 النهائي بحجم 21.0 ميغابايت. في حين استغرق المخطط الزمني البصري نفسه تماماً عند بنائه باستخدام HyperFrames نحو 22.4 ثانية فقط، بحجم ملف بلغ 11.2 ميغابايت، وتجاوز التدقيق النوعي الآلي المكوّن من 18 إطاراً بنتيجة 8.6 من 10.

يمثل هذا تسريعاً بمقدار 3.3 أضعاف مع تقليص حجم الملف بنسبة 47%، دون أي فقدان في حدة الخطوط أو التزامن الصوتي. نورد هنا التحليل التقني لأسباب وصول المتصفح الخفي إلى حدوده القصوى في إنتاج الفيديو، وكيف يغير الرسم المباشر عبر معالج الرسوميات اقتصاديات الوسائط البرمجية.

ضريبة المتصفح بدون واجهة#

لفهم أسباب تباطؤ Remotion أثناء معالجة دفعات الفيديو، يتعين تتبع كيفية تحويل Chromium للكود البرمجي إلى إطارات مرئية.

لا يتعامل Remotion مع المتصفح كشاشة عرض آنية، بل يتقدم عبر الزمن الافتراضي إطاراً تلو الآخر. وبالنسبة لمقطع مدته 38.8 ثانية بمعدل 30 إطاراً في الثانية، فإن العملية الحسابية واضحة:

38.8 ثانية × 30 إطاراً/ثانية = 1,164 إطاراً

لكل إطار منفرد من هذه الإطارات البالغ عددها 1,164 إطاراً، ينفذ المسار التسلسل التالي:

1. إرسال أمر تقدم الوقت الافتراضي إلى بيئة تشغيل React.
2. حساب تحديثات تخطيط React ومقارنة المكونات وتحديثات أنماط CSS.
3. تنقيط شجرة عناصر DOM إلى طبقة التركيب داخل Chromium.
4. التقاط مخزن البيكسلات المؤقت عبر بروتوكول DevTools أو نقل بيانات canvas.
5. تمرير مصفوفة البيكسلات الخام عبر قنوات الاتصال بين العمليات (IPC) إلى عملية FFmpeg خارجية.
6. ترميز الإطار الخام إلى تنسيق H.264.

حتى مع المعالجة المتوازية متعددة العمليات، تقضي هذه البنية أغلب دورات المعالج في تحويل ونقل البيانات عبر حدود العمليات المنفصلة. أنت تشغل محركات متصفح كاملة لتعمل فقط كآلات لالتقاط لقطات الشاشة. ويقضي المعالج المركزي وقتاً في إدارة المخازن المؤقتة وحسابات تخطيط الصفحات أطول بكثير من الوقت المستغرق في ترميز الفيديو الفعلي.

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

الرسم المباشر عبر معالج الرسوميات: ما يقدمه HyperFrames#

يتعامل HyperFrames مع الفيديو البرمجي انطلاقاً من مسار معالجة الرسوميات المباشر وليس من طبقة أتمتة المتصفح.

عوضاً عن تشغيل متصفح كامل لاستخراج إطارات الصور عبر جسر تصحيح الأخطاء، يترجم HyperFrames شجرة التركيب التعريفية مباشرة إلى تعليمات رسومية صريحة. النصوص وأشكال SVG والصور والمسارات الصوتية تتواجد جميعها ضمن خط زمني موحد وحتمي.

عند استدعاء المترجم، يتم تقييم الإطارات بصورة أصلية:

# أمر استدعاء مجمع SceneVerso
hyperframes render \
  --project ./timeline \
  --out ./out/render.mp4 \
  --width 1920 \
  --height 1080 \
  --fps 30

نظراً لأن تقييم المشهد يتم دون عزل لعمليات Chromium ودون استدعاءات DevTools المتعاقبة، يتجنب مسار المعالجة عنق زجاجة الاتصال بين العمليات كلياً. يقرأ النظام حالة الخط الزمني مباشرة من الذاكرة، ويطبق التحويلات المدعومة بالعتاد، ويبث النتائج مباشرة إلى أداة الترميز.

نتائج القياس: بيانات الأداء جنباً إلى جنب#

قمنا باختبار كلا المحركين على نفس المدخلات الإبداعية: 38.80 ثانية من الفيديو تضم 4 مشاهد سردية، ونصوصاً حركية متزامنة، وأيقونات SVG، وخلفية صوتية مع خفض تلقائي لمستوى الصوت، و11 انتقالاً بصرياً.

فيما يلي قراءات الأداء المسجلة مباشرة من بيئات الإنتاج:

يعد مقياس معامل الوقت الفعلي حاسماً لأدوات التطوير. فالمسار الذي يعمل بمعدل 0.52x يجبر المستخدم أو نظام المعالجة الخلفي على الانتظار نحو ثانيتين لكل ثانية فيديو واحدة يتم توليدها. أما عند معدل 1.73x، تصبح سرعة المعالجة أسرع من سرعة العرض، حيث تتم معالجة مقطع تسويقي مدته 30 ثانية في أقل من 18 ثانية.

أما الانخفاض في حجم الملف فكان ملحوظاً أيضاً. تم ضبط كلا المحركين لإخراج فيديو H.264 بدقة 1080p القياسية. غير أن HyperFrames يدير مخازن الألوان ودمج الشفافية مباشرة قبل مرحلة الترميز، مما يولد خلفيات نقية وحواف متجهة حادة دون تشوهات التنعيم الناتجة عن محركات المتصفح، مما يسهم في زيادة كفاءة الضغط بشكل كبير.

الحالات التي نحتفظ فيها بمحرك Remotion#

القرارات الهندسية مبنية دائماً على الموازنة بين المزايا والتكاليف. واستبدال Remotion كمحرك افتراضي لا يعني التخلي عنه نهائياً.

يظل Remotion خياراً متميزاً في مهمتين أساسيتين يدعمهما SceneVerso كمسارات بديلة:

1. الرسوم البيانية الرياضية المعقدة والتخطيط الديناميكي: عند معالجة مخططات تعتمد على التفاف Flexbox الديناميكي أو جداول متغيرة أو مسارات SVG تعتمد على قياس النصوص البرمجية في المتصفح (measureText و getComputedTextLength)، يقدم Chromium دقة تخطيط متفوقة.
2. مكونات منظومة React المتقدمة: إذا كان المشروع يعتمد على شجرة مكونات React خارجية متخصصة (مثل جداول البيانات التفاعلية أو خرائط Leaflet)، فإن تنفيذها في بيئة React الأصلية يظل الخيار الأكثر ملاءمة.

بالنسبة لهذه الحالات التخصصية، يحتفظ SceneVerso بمحرك Remotion كبديل صريح. يتيح ملف المخطط (Manifest) تحديد المحرك المطلوب لكل مشروع:

{
  "version": "1.0",
  "project": "architecture-diagram",
  "engine": "remotion",
  "scenes": [...]
}

وفي حال عدم التحديد، يعتمد النظام تلقائياً على HyperFrames للمقاطع السردية والشروحات التوضيحية.

التأثير المباشر على إنتاج SceneVerso#

يغير هذا التحول اقتصاديات مسار توليد الفيديو المؤتمت بالكامل.

يعمل SceneVerso وفق مبدأ صارم: تتم مراجعة مخطط الإنتاج والموافقة عليه قبل إنفاق أي تكلفة على نماذج الصوت الخارجية أو توليد المكونات السحابية. وتتراوح التكلفة المستهدفة بين 0.13 و 0.16 دولار لكل دقيقة فيديو نهائية:

• توليد الصوت عبر ElevenLabs: نحو 0.09 دولار للدقيقة (نماذج Voice DNA مخصصة)
• ترخيص المقاطع الموسيقية الخلفية: نحو 0.04 دولار للدقيقة
• طاقة معالجة التوليد والتركيب: نحو 0.01 دولار للدقيقة (على خوادمنا المخصصة)

عندما تستغرق معالجة المقطع الواحد 74 ثانية، تتعرض خوادم المعالجة لضغط شديد أثناء الدفعات الكبيرة. أما عند 22 ثانية للمقطع، يستطيع خادم معالجة مستقل إنجاز أكثر من 150 مقطع فيديو نهائي في الساعة دون تباطؤ حراري أو استنزاف للذاكرة.

في مسارات الوسائط البرمجية، لا تمثل السرعة مجرد راحة للمستخدم، بل هي الفارق الحاسم بين أداة تفاعلية سريعة ومهام خلفية بطيئة.