HyperFrames: إطارٌ مفتوح المصدر يحوّل صفحة HTML إلى فيديو MP4، مصمَّمٌ لوكلاء الذكاء الاصطناعي

تريد مقطع فيديو قصيراً يعرّف بمنتجٍ أو يشرح فكرة: عنوانٌ يظهر بحركةٍ سلسة، ومخطّطٌ بيانيّ ينمو أمام العين، ولقطاتٌ تتوالى فوق موسيقى. أمامك طريقان معتادان، وفي كلٍّ منهما عائق.

الطريق الأول محرّرٌ زمنيّ (timeline editor) بواجهةٍ رسومية: تسحب العناصر وتُفلتها بيدك على شريطٍ زمنيّ. هذا عمليٌّ لمقطعٍ واحد، لكنه بطيء ويدويٌّ بالكامل، ولا يمكن توليده آلياً ولا مراجعته كما يُراجَع الكود. والطريق الثاني أن تكتب الفيديو برمجياً بإطارٍ مثل Remotion، لكنّه مبنيٌّ على React، ويحتاج خطوة بناء (build step)، وهو من أصعب الصيغ على نماذج الذكاء الاصطناعي أن تولّدها مقارنةً بـ HTML الصِّرف.

ويقدّم HyperFrames طريقاً ثالثاً: التركيبة (composition) التي تصف الفيديو ليست مشروعاً في محرّرٍ خاصّ ولا شجرة مكوّنات React، بل صفحة HTML عادية. تكتب الصفحة، وتشغّل أمراً واحداً، فيخرج لك ملف MP4. وأثر هذا الاختيار أكبر ممّا يبدو عليه: حين يصير مصدرُ الفيديو صفحةَ ويب، يصير كلُّ ما يعرفه المطوّرون ووكلاؤهم عن HTML وCSS والرسوم المتحرّكة صالحاً لصناعة الفيديو مباشرةً. والعبارة التي تعرّف بها الأداةُ نفسَها هي: «اكتب HTML، اعرض فيديو، مبنيٌّ للوكلاء».

وHyperFrames غير منتج HeyGen الأشهر، وهو الأفاتار الرقميّ الناطق الذي يولّد شخصاً يتكلّم من نصّ. إنه أداةٌ منفصلة تماماً: محرّكٌ هندسيّ يأخذ كوداً ويُخرج ملف فيديو، لا أكثر. وقد فتحت HeyGen مصدره تحت رخصة Apache 2.0، فصار متاحاً للجميع قراءةً وتعديلاً واستعمالاً، وجاوز عشرات الآلاف من النجمات (stars) على GitHub سريعاً.

لماذا HTML بالذات، ولماذا «مبنيٌّ للوكلاء»

وراء عبارة «مبنيٌّ للوكلاء» ثلاثةُ قراراتٍ في التصميم، كلٌّ منها يخدم أن يقود وكيلُ الذكاء الاصطناعي الأداةَ من أوّلها إلى آخرها.

الأول هو اختيار HTML صيغةً للمصدر. نماذج اللغة الكبيرة (LLMs) تدرّبت على كمٍّ هائل من صفحات الويب، فصار HTML وCSS من أكثر ما تجيد توليده وأوثقِه. وحين تطلب من وكيلٍ أن «يصنع فيديو إطلاقٍ لمنتج»، فأن يكتب صفحةَ HTML تصف المشاهد أقربُ إلى ما يتقنه من أن يكتب مشروعَ React كاملاً بخطوة بنائه وتبعيّاته. فالصيغة التي يولّدها الوكيل بثقةٍ هي الصيغة التي ينبغي أن يقبلها المحرّك، وهذا ما فعله HyperFrames.

الثاني هو تصميم سطر الأوامر (CLI) ليعمل بلا تفاعلٍ بشريّ. كلّ أوامره تأخذ مدخلاتها من الأعلام (flags) لا من أسئلةٍ تفاعلية، ومخرجاتها نصٌّ صريح، وتتوقّف فوراً عند أول خطأ (fail-fast). فيستطيع الوكيل تشغيل كلّ أمرٍ دون أن ينتظر إنساناً يجيب عن سؤالٍ في المنتصف، وهذا شرطٌ ضروريّ لأتمتةٍ حقيقية.

الثالث هو الحتميّة (determinism)، وهي محور عمل الأداة كلّه: فنتائجه لا تتغيّر بين تشغيلٍ وآخر ما دام المدخل واحداً، وهذا ما يجعل الإخراج الآليّ والاختبار المتكرّر عمليةً يُعتمد عليها لا مقامرة.

كيف يعمل: الحتميّة والتقاط الإطارات

الطريقة الساذجة التي قد تخطر ببالك أولاً هي أن تفتح الصفحة في متصفّح وتسجّل الشاشة بينما تعمل الرسوم المتحرّكة. والمشكلة في هذا التسجيل اللحظيّ (real-time) أنه محكومٌ بساعة الحائط (wall-clock): إن كان المشهد ثقيلاً وتأخّر المتصفّح لحظةً عن مواكبة الزمن الحقيقيّ، سقطت إطاراتٌ من الفيديو. والأسوأ أن النتيجة تختلف من جهازٍ لآخر ومن تشغيلٍ لآخر حسب حِمل المعالج، فلا تملك مقطعاً واحداً مضموناً، بل تسجيلاً يتأثّر بظروف اللحظة.

ويعالج HyperFrames هذا بأن يتحكّم في الزمن نفسه بدل أن يتركه يجري ويلاحقه بالتصوير. فبدل تشغيل الرسوم المتحرّكة وتسجيلها، يحسب لحظةَ كلّ إطارٍ على حدة، ويأمر المتصفّح: «الزمن الآن هو بالضبط الثانية 1.5، ارسم المشهد كما يجب أن يكون عندها»، ثم يلتقط تلك اللقطة، ثم ينتقل إلى الإطار التالي فيقول: «والآن الزمن 1.542 ثانية»، وهكذا. وتحديدُ أيّ إطارٍ يقابل أيّ لحظةٍ يتبع معادلةً بسيطة: رقم الإطار يساوي الجزء الصحيح من حاصل ضرب الزمن في معدّل الإطارات (frame = floor(time × fps))، فعند معدّل 24 إطاراً في الثانية يقابل الإطارُ رقم 36 اللحظةَ 1.5 ثانية. ويفعل ذلك عبر واجهةٍ في Chrome اسمها beginFrame تتيح قيادة ساعة الصفحة من الخارج بدل تركها لساعة الحائط.

ويشبه الأمر الفرق بين مصوّر الفيديو المتّصل ومصوّر الحركة المتوقّفة (stop-motion): الأول إن أبطأ فاتته لحظات، أمّا مصوّر الحركة المتوقّفة فيُهيّئ المشهد عند كلّ لحظةٍ بعينها ويلتقط صورتها ثم ينتقل، فلا تفوته لحظةٌ مهما تمهّل. وHyperFrames يعمل كالثاني: يُجمّد الزمن عند كلّ إطار، فيلتقطه كاملاً غير منقوص.

ونتيجة هذا أن اللحظةَ عند الثانية الثالثة تُرسَم دائماً من الحالة نفسها للرسوم المتحرّكة، مهما كان الجهاز بطيئاً. فالمشهد الثقيل يُخرَج ببطءٍ أكبر فحسب، دون أن يفقد إطاراً واحداً. وهذا يضمن «الحتميّة»: المدخل نفسه يعطي الإطارات نفسها والملف نفسه دائماً. ولهذا ثمرةٌ عمليّة لا تتحقّق مع التسجيل اللحظيّ: يصير الفيديو قابلاً للاختبار الآليّ، فتُخرجه وتقارن بكسلاته بنسخةٍ مرجعية لتكشف أيّ تغيّرٍ غير مقصود تماماً كاختبار الشيفرة، ويصير قابلاً للتخزين المؤقّت (cache) لأن النتيجة ثابتة، ويصير قابلاً للتوازي: إذ يمكن تقسيم الإطارات على عدّة عمّالٍ في السحابة، يُخرج كلٌّ منهم نطاقه، ثم تُجمَع الإطارات في ملفٍ واحد. وهذا الأخير ما تتيحه الأداة عبر AWS Lambda لتسريع المشاريع الكبيرة.

وبعد التقاط الإطارات يأتي دور FFmpeg، وهو الذي يرمّز (encode) سلسلة الصور الملتقَطة ويجمعها في ملف MP4 نهائيّ، ويمزج معها مساراتِ الصوت. والناتج الأساسيّ والموثّق هو MP4، ويمكن إخراج صيغٍ أخرى مثل MOV وWebM أيضاً.

الشرط الخفيّ: الرسوم يجب أن تكون «قابلة للقفز»

يترتّب على هذه الآلية شرطٌ جوهريّ يجب أن يعيه كلُّ من يكتب لـ HyperFrames. فما دام المحرّك يقفز إلى أيّ لحظةٍ يشاء مباشرةً، فالرسم المتحرّك يجب أن يكون قابلاً للقفز (seekable)، أي قادراً على الانتقال إلى أيّ نقطةٍ زمنية دون أن يُشغَّل من بدايته إلى تلك النقطة. والأداة الطبيعية لهذا هي مكتبة GSAP: تُنشئ بها خطاً زمنياً (timeline) موقوفاً (paused)، فيصير المحرّك قادراً على «تحريكه» إلى زمن كلّ إطار.

والفخّ الأشهر هنا أنّ أيّ حركةٍ تعتمد على الزمن الحقيقيّ المنقضي تكسر الحتميّة. فالأنماط التي تقيس مرور الوقت الفعليّ (مثل Date.now() أو setTimeout أو عدّاد requestAnimationFrame) لا معنى لها حين يُجمَّد الزمن ويُقفَز إليه، لأنها تفترض أن الساعة تجري فعلاً. فالحركة يجب أن تُقاد بالزمن الافتراضيّ للإطار، لا بالزمن الحقيقيّ. ولأن هذا القيد لا يخصّ GSAP وحدها، صمّم HyperFrames ما يسمّيه «مُكيّف الإطار» (Frame Adapter)، وهو طبقةٌ تسمح لأيّ محرّك رسومٍ قابلٍ للقفز بأن يعمل معه ما دام قادراً على القفز إلى لحظةٍ بعينها: CSS، وLottie، وThree.js للرسوم ثلاثية الأبعاد، وAnime.js، وواجهة رسوم الويب القياسية (WAAPI).

بنية التركيبة، وكيف تبدأ عملياً

التركيبة في HyperFrames صفحة HTML لا أكثر: لا خطوة بناء، ولا حزم (bundler)، ولا React. تشغّل أمر المعاينة فتُعرض في متصفّحك مباشرةً كما ستُخرَج. وما يميّز هذه الصفحة عن أيّ صفحة ويب هو بضع سماتٍ من نوع data-* تصف التوقيت والطبقات:

• عنصرٌ جذر يحمل data-composition-id ومقاسَي العرض والارتفاع (data-width، data-height).
• العناصر التي تظهر وتختفي بمرور الزمن تُوسَم بالصنف class="clip"، وتحمل data-start (لحظة الظهور بالثواني)، وdata-duration (مدّة البقاء)، وdata-track-index (رقم الطبقة للترتيب فوق بعضها).
• عناصر audio وvideo تحمل السمات نفسها، مع data-volume للصوت، فيمزجها FFmpeg في المسار الصوتيّ النهائيّ.

والحركة نفسها تُبنى بخطٍّ زمنيّ من GSAP يُنشأ موقوفاً ويُسجَّل ليقرأه المحرّك ويقفز به إلى زمن كلّ إطار. وأصغر مثالٍ مكتمل هو عنوانٌ مدّتُه خمس ثوانٍ، يظهر متدرّجاً وهو يصعد قليلاً خلال أول ثانيةٍ منها:

<div id="stage" data-composition-id="hello" data-width="1920" data-height="1080">
  <h1 class="clip" data-start="0" data-duration="5" data-track-index="0">Hello, world</h1>
</div>

<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
<script>
  const tl = gsap.timeline({ paused: true });
  tl.from("#stage h1", { opacity: 0, y: 40, duration: 1 });

  // register the paused timeline so the renderer can seek it per frame
  window.__timelines = { hello: tl };
</script>

ولتشغيل هذا وإخراجه فيديو، تحتاج أولاً إلى المتطلّبين الوحيدين: Node.js في نسخته 22 أو أحدث، وFFmpeg مثبّتاً على جهازك. ثم لا حاجة لتثبيت الحزمة نفسها، إذ يعمل كلُّ شيءٍ عبر npx:

# check prerequisites
node --version          # expect v22 or higher
brew install ffmpeg     # macOS; use "apt install ffmpeg" or "winget install ffmpeg" elsewhere

# scaffold, preview, and render
npx hyperframes init my-video
cd my-video
npx hyperframes preview                 # live browser preview with hot reload
npx hyperframes render --output out.mp4 # capture every frame and encode to MP4

وأمر preview يفتح معاينةً في المتصفّح تُحدَّث فور تعديلك للصفحة، فتضبط الحركة بعينك قبل الإخراج. وأمر render هو الذي يُجري العملية كاملةً: يفتح Chrome الخفيّ، ويقفز إطاراً إطاراً، ويمرّر الالتقاطات إلى FFmpeg حتى يخرج الملف. وإلى جانبهما أوامرُ خدمةٍ مفيدة مثل lint للتحقّق من صحّة التركيبة قبل الإخراج، وdoctor لتشخيص البيئة حين يتعطّل شيء.

من وصفٍ بالكلام إلى ملف MP4: الوكلاء والمهارات

ويظهر أثر هذا التصميم أوضح ما يكون حين يقود الأداةَ وكيلُ ذكاءٍ اصطناعيّ. فمع HyperFrames مجموعةٌ من «المهارات» (skills) الجاهزة التي تعمل داخل وكلاء البرمجة الداعمة لها، مثل Claude Code وCursor وGemini CLI، وتُثبَّت بأمرٍ واحد:

npx skills add heygen-com/hyperframes

وبعد التثبيت تصير لديك أوامرُ مائلة (slash commands) داخل الوكيل، على رأسها مهارةٌ موجِّهة اسمها /hyperframes تستقبل طلبك وتوزّعه على المهارة المناسبة. فتصف الفيديو الذي تريده بالكلام، فيكتب الوكيلُ صفحةَ HTML وخطَّها الزمنيّ، ثم يستدعي HyperFrames ليُخرجها MP4. وبذلك ينتقل وكيلُ البرمجة من كتابة الكود إلى تسليم ملف الفيديو كاملاً.

والمهارات متخصّصة بحسب نوع المقطع: /product-launch-video لفيديوهات إطلاق المنتجات وجولات المواقع، و/motion-graphics للرسوم المتحرّكة القصيرة، و/slideshow للعروض التقديمية، و/faceless-explainer لمقاطع الشرح. ومن أنفعها عملاً /pr-to-video الذي يحوّل طلب دمجٍ (pull request) على GitHub إلى فيديو يلخّص تغييراته، و/remotion-to-hyperframes الذي يساعد على نقل تركيبات Remotion المبنيّة على React إلى صيغة HTML التي يفهمها HyperFrames.

أكثر من محرّك: النظام حوله

وHyperFrames محرّك إخراجٍ قبل كل شيء، لكن حوله أدواتٌ تصل بين الكود والواجهة الرسومية. أبرزها محرّر «الإطارات المفتاحية» (Keyframes)، وهو محرّرٌ زمنيّ بصريّ ثنائي الاتجاه: حين تحرّك عنصراً بيدك على الشريط الزمنيّ يُحدَّث كودُ GSAP المقابل تلقائياً، وحين تعدّل الكود يتحرّك التمثيل البصريّ معه. فيبقى الكود والواجهة نسختين متزامنتين لشيءٍ واحد، وهذا يريح من يضبط الحركة بعينه ومن يتحكّم بها بالكود في آنٍ معاً.

وإلى جانبه كتالوج (catalog) من أكثر من مئة مكوّنٍ جاهز تُضيفه بأمر npx hyperframes add، مثل مخطّطٍ بيانيّ متحرّك أو انتقالٍ بصريّ بين المشاهد؛ ومشغّلٌ قابلٌ للتضمين (<hyperframes-player>) لعرض التركيبات في صفحة ويب؛ وإخراجٌ سحابيّ عبر AWS Lambda للمشاريع التي تحتاج سرعةً وتوازياً. ومن دلائل جِدّيّته أن HeyGen نفسها تبني فيديوهات إطلاق منتجاتها به وتنشر تركيباتها علناً، وأن مشاريع معروفة مثل tldraw وTanStack مذكورةٌ بين مستعمليه.

لماذا يهمّ هذا فعلاً

أثر هذا كلّه أنّ الفيديو ينتقل إلى عالم الكود بأدواته. فحين يصير الفيديو صفحةَ HTML في مستودعٍ، يمكن حفظه في نظام تحكّمٍ بالإصدارات مثل Git، ومقارنة تغييراته سطراً سطراً (diff)، ومراجعته في طلب دمجٍ كما تُراجَع أيّ شيفرة، وتوليده ضمن خطّ تكاملٍ مستمرّ (CI) بلا يدٍ بشرية، وقولبته وإعادة استعماله عبر مئات المقاطع. وهذا معنى «الفيديو ككود» (video as code)، على غرار «البنية التحتية ككود» التي غيّرت طريقة إدارة الخوادم.

وعلى مستوى سير العمل مع الذكاء الاصطناعي، صار بمقدور الوكيل أن يُنتج ملف فيديو حقيقياً من طلبٍ باللغة الطبيعية، بعد أن كان مخرَجُه محصوراً في النصّ والصورة. ومن يبني خطوط إنتاج محتوًى آلية (مقاطع تعليمية، ملخّصات إصداراتٍ برمجية، بطاقات اجتماعية متحرّكة) يصير توليد الفيديو عنده خطوةً في السكربت بدل أن يكون مهمّةً يدوية.

HyperFrames مقابل Remotion

المقارنة الطبيعية هي مع Remotion، الإطار الأشهر لتوليد الفيديو برمجياً. كلاهما يحوّل كوداً إلى فيديو، لكنهما ينطلقان من فلسفتين مختلفتين. فRemotion مبنيٌّ على React، ويناسب الفرق المستثمرة أصلاً في هذا النظام؛ لكنه يحتاج خطوة بناءٍ وحزم، وتُكتب حركته عبر خطاطيف (hooks) تحسب الحالة لكل إطار. أمّا HyperFrames فيقوم على HTML صِرف بلا بناء، وعلى نموذج القفز إلى الإطار عبر مُكيّفاتٍ قابلة للقفز، وهو مصمَّمٌ في الأساس ليقوده الوكلاء لأن HTML أقربُ الصيغ إليهم.

والقاعدة العملية أنّ فريقك إن كان يعيش في React ولديه بنيةٌ قائمة عليه، فقد يظلّ Remotion أنسب. أمّا إن كنت تريد أن يقود وكيلٌ العملية، أو تفضّل HTML الصِّرف بلا خطوة بناء، فـ HyperFrames صُمّم لهذا تحديداً.

القيود: أين لا يصلح، وما الذي يكسر الحتميّة

أوّل حدوده أنه ما زال في سلسلة 0.7، أي قبل الإصدار 1.0 المستقرّ، فواجهته وسلوكه قد يتغيّران بين الإصدارات، وهو ما ينبغي أخذه في الحسبان قبل البناء عليه في الإنتاج.

وثانيها أنه ليس تطبيقاً بزرٍّ واحد: فهو يفترض إلفةً بسطر الأوامر ومعرفةً بـ HTML وCSS والحركة، وتثبيتَ Node وFFmpeg. ومن يبحث عن محرّرٍ رسوميّ يسحب فيه ويُفلت دون كتابة كود سيجده تحوّلاً ذهنياً لا يناسب الجميع.

وثالثها أن الحتميّة نفسها هشّة إن لم تحترم قواعدها: فأيّ شيءٍ يعتمد على الزمن الحقيقيّ أو العشوائية يكسر إعادة الإنتاج، مثل Date.now() أو رقمٍ عشوائيّ بلا بذرةٍ (seed) ثابتة أو حركةٍ مبنيّة على ساعة الحائط أو طلبِ شبكةٍ يتغيّر ردّه. فالحركة يجب أن تكون قابلةً للقفز، والتركيبة يجب أن تكون مغلقةً على نفسها بلا مصادر متغيّرة.

ورابعها حدُّ طبيعته: فهذا فيديو مُخرَجٌ من متصفّح، وهو ممتازٌ للرسوم المتحرّكة والنصوص المتحرّكة وأشكال CSS ورسوم SVG وتصوّرات البيانات (data visualizations) والشرائح والطبقات فوق لقطاتٍ موجودة. لكنه ليس كاميرا، ولا محرّرَ مونتاجٍ لمشاريع تقوم أساساً على لقطاتٍ مصوّرة كثيرة؛ فإن كان مشروعك في جوهره مقاطعَ مصوَّرة، فليست هذه أداتَه، وإن كان يستطيع أن يضيف التعليقات والرسوم فوق فيديو قائم. وأخيراً، بما أنه يلتقط إطاراً إطاراً لا في الزمن الحقيقيّ، فإخراج المشاهد الثقيلة أو الطويلة أبطأ من التسجيل اللحظيّ، وهذا ثمن الحتميّة.

خاتمة

الأسبابُ نفسها التي قد تجعل الأداة غير مريحةٍ لإنسان، وهي كتابة HTML بدل السحب والإفلات وتشغيل أوامر في الطرفية بدل الضغط على زرّ، هي ما يجعلها مناسبةً لوكيل ذكاءٍ اصطناعيّ: صيغةٌ يتقنها، وأوامرُ يقودها بلا تدخّل، ونتيجةٌ ثابتة يمكن اختبارها. فهي لا تحاول أن تجعل صناعة الفيديو أسهلَ على البشر، بل تنقلها إلى حيث صار الوكلاء يعملون فعلاً.

أمّا القرار العمليّ فمعلّقٌ على استقرار الإصدار: من يبني اليوم خطَّ إنتاجٍ على أداةٍ في سلسلة 0.7 يقبل أن تتغيّر واجهتها تحته بين إصدارٍ وآخر، ومن ينتظر 1.0 يؤجّل مكسباً حقيقياً في أتمتة الفيديو. والأقرب للتجربة الآن هو المقاطع القصيرة المتكرّرة التي تُولَّد آلياً وتُعاد بلا كلفة، لا المشاريع الطويلة التي يصعب إعادة بنائها إن تغيّرت الأداة تحتها.

للتوسّع والبدء العمليّ: