مدخل واحد، برامج قنوات FAST متعددة

مدخل واحد، مئات البرامج — تشغيل قنوات FAST على مدار الساعة طوال أيام الأسبوع على MediaLive

قناة FAST التي تعمل على مدار الساعة طوال أيام الأسبوع تعرض مئات البرامج الفريدة يوميًا، كل يوم، إلى الأبد. يحد AWS MediaLive من القناة إلى 20 مرفق إدخال. التصميم البسيط — مدخل واحد لكل فيديو — ينفد من الفتحات قبل الغداء ويجبر على إعادة تشغيل القناة مما يؤدي إلى انقطاع البث المباشر. لقد حللنا هذا باستخدام مدخل ديناميكي واحد يخدم كل برنامج ستعرضه القناة، وطبقة من التنسيق على مستوى البرنامج تحافظ على الجدول الزمني ذاتي الشفاء عبر عمليات النشر، والإخفاقات الجزئية، وتعديلات المشغل.

هذه هي قصة الهندسة حول كيفية عمل هذا التنسيق فعليًا.

نظرة عامة سريعة

المشكلة التجارية

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

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

مقدمة عن MediaLive في 60 ثانية

AWS MediaLive هو مشفر سحابي طويل الأمد. تعطيه واحدًا أو أكثر من المدخلات (تدفقات المصدر أو عناوين URL للملفات) وجدول إجراءات محددة بالوقت — التبديل إلى هذا المدخل، تشغيل هذا التراكب، إدراج هذه الإشارة. يعمل المشفر إلى الأبد، وينفذ الإجراءات في توقيتاتها المجدولة ويصدر بيان HLS الذي يستهلكه مشغل المشاهد.

تحدد حدود AWS كل شيء في الأسفل:

• 20 مرفق إدخال لكل قناة. حد صارم. قناة "أفضل 20 فيلمًا" المصممة بشكل بسيط مع مدخل واحد لكل فيديو تملأ الحد في الفيلم 21.
• 1500 إجراء جدولي لكل قناة. أيضًا حد صارم. كل برنامج هو عدة إجراءات (تبديل المدخل، العلامة المائية لكل نسخة، إشارات الإعلانات، تبديل slate)، لذا فإن السقف الحقيقي أقرب إلى بضع مئات من البرامج في أي وقت.

كلا الحدين مهمان لقناة تعمل على مدار الساعة طوال أيام الأسبوع من المتوقع أن تعرض محتوى فريدًا إلى ما لا نهاية.

لماذا تفشل الأساليب البسيطة

كل الطرق الواضحة تفشل بطرق مختلفة:

• "مدخل واحد لكل برنامج." يكمل حد 20 مرفقًا في اليوم الأول. إضافة المزيد يتطلب إعادة إنشاء القناة — وإعادة إنشاء القناة تستغرق 60-90 ثانية يتم خلالها فقدان البث المباشر. غير مقبول على خدمة تعمل على مدار الساعة طوال أيام الأسبوع.
• "إعادة إنشاء القناة لكل نشر." نفس المشكلة، كل نشر. يواجه المشاهدون انقطاعًا في كل مرة تتغير فيها البرمجة. هذا ليس خيارًا حقيقيًا لقناة من المفترض أن تكون مباشرة.
• "تشفير الأسبوع بأكمله مسبقًا في ملف واحد ضخم متكرر." يقتل نموذج التحرير. تريد إعادة ترتيب الغد؟ أعد تشفير الأسبوع بأكمله. تريد إدراج إعلان؟ أعد تشفير. السبب الكامل لنجاح قنوات FAST كعمل تجاري هو البرمجة الديناميكية وإدراج الإعلانات لكل فاصل — حرق كل شيء في ملف واحد يغلق على كليهما.
• "تشغيل قنوات متعددة بالتوازي." يحتاج إلى أن يقوم المشغل بالتبديل بينها، ويضاعف تكلفة AWS، ويفصل بين الصوت وMediaPackage وCDN. لا يحل المشكلة بقدر ما يضاعفها.

الرافعة التي كانت لدينا هي ميزة موثقة من AWS — العنصر النائب $urlPath$ على مدخل ديناميكي — والحرية في بناء أي تنسيق نريده فوقها.

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

حلنا

قناة MediaLive واحدة. مدخل ديناميكي واحد مرتبط بالضبط بعنوان URL $urlPath$. مدخل slate واحد لملء الفجوات. عند كل حدود برنامج، يقوم إجراء InputSwitchScheduleActionSettings بتجاوز عنوان URL للمدخل الديناميكي بمسار S3 الفعلي لذلك البرنامج. لا تحتاج القناة أبدًا إلى مرفق إدخال جديد، ولا تحتاج إلى إعادة تشغيل، ولا تذهب إلى وضع عدم الاتصال.

العمل المثير للاهتمام هو طبقة التنسيق التي تعمل فوق هذا المدخل الواحد — تسمية كل إجراء بمعرف البرنامج بحيث يمكن تنظيف الأيتام بعد الفشل، وملء الفجوات ≥ 6 ثوانٍ ببطاقة بحيث لا يرى المشاهد إطارًا ثابتًا، وتفعيل العلامة المائية في لحظة محسوبة بعد كل تبديل مدخل بحيث لا يومض التراكب عبر الإطارات المؤقتة، والتحقق المسبق ضد سقف 1500 إجراء بحيث تفشل عمليات النشر في واجهة المستخدم بدلاً من منتصف الرحلة على AWS.

الرسم البياني 1 · بنية القناة

البنية

• مدخل slate — أصل ثابت مرفق بالقناة لملء الفجوات بين البرامج.
• مدخل ديناميكي — تم إنشاؤه مرة واحدة مع Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. عنوان URL هو عنصر نائب؛ يتم توفير المسار الفعلي لكل برنامج في وقت الجدولة.
• منسق Lambda (fastChannel-lambda-fun/index.js) — يمتلك كل نشاط يظهر على القناة. يولد معرف programId سداسي 8 بايت لكل برنامج ويضع علامة على كل إجراء متعلق به.
• جدول MediaLive — قائمة مرتبة واحدة من الإجراءات، جميعها تتدفق عبر BatchUpdateScheduleCommand. مقيدة بـ 1500 إجراء بواسطة AWS.
• التحقق المسبق من الخلفية (schedule.service.ts) — يستدعي GET_SCHEDULE_COUNT من Lambda قبل كل نشر ويرفض المتابعة إذا كانت الإجراءات الجديدة ستتجاوز الحد.

• مسح الأيتام (sweepIncompleteProgramGroups) — يعمل بعد كل نشر. يجمع الإجراءات حسب programId، ويحذف أي مجموعة تفتقد إجراء input-switch الخاص بها.

   

قرارات هندسية رئيسية

1. مدخل ديناميكي واحد، تجاوز عنوان URL واحد لكل برنامج

تم إنشاء المدخل الديناميكي مع Sources: [{ Url: "$urlPath$" }]. عند كل حدود برنامج، يصدر Lambda إجراء InputSwitchScheduleActionSettings الذي يوفر UrlPath: [program.videoUrl] — عنوان URL الفعلي لـ S3 لملف MP4 الخاص بذلك البرنامج. يقوم MediaLive باستبدال العنصر النائب في وقت التنفيذ ويسحب من المصدر الحقيقي.

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

الرسم البياني 2 · تجاوز عنوان URL للمدخل الديناميكي

المقايضة التي قمنا بها عن قصد. المدخل الديناميكي لا يتحقق مسبقًا من صحة عنوان URL — يقوم MediaLive فقط بحل العنصر النائب في وقت التبديل، لذا يظهر 404 كخطأ في البث بدلاً من رفض في وقت النشر. نقبل هذا التكلفة مقابل البساطة المعمارية لمدخل واحد. يتحقق التحقق المنفصل من الخلفية من صحة المصادر المشوهة قبل النشر.

2. أسماء الإجراءات المميزة بالبرنامج تمكن الشفاء الذاتي

كل إجراء يصدره Lambda يحمل معرف البرنامج السداسي 8 بايت programId في اسمه: input-switch-${programId}، watermark-on-${programId}-${rendition}، ad-break-start-${programId}-${i}، program-end-${programId}، slate-switch-${programId}.

بعد كل نشر، يقوم sweepIncompleteProgramGroups بإدراج كل إجراء حاليًا على القناة، ويجمعها حسب programId المضمنة، ويحذف أي مجموعة تفتقد إجراء input-switch الخاص بها. هذا هو مسار التنظيف للفشل الجزئي في النشر، والتعديلات المتسارعة، وأي حالة أخرى يمكن أن تترك القناة مع نصف إجراءات البرنامج عالقة.

ترميز اسم الإجراء هو آلية الهوية بأكملها. MediaLive نفسها ليس لديها مفهوم "البرنامج" — طبقة التنسيق تسقط واحدة عليها عبر تقاليد التسمية.

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

3. قاعدة 6 ثوانٍ للـ slate

نادرًا ما تتطابق البرامج بشكل مثالي — هناك دائمًا تقريبًا فجوة لبضع ثوانٍ بين نهاية ملف MP4 واحد وبداية البرنامج المجدول التالي. يقوم التنسيق بإصدار إجراء تبديل slate كلما كانت هذه الفجوة ≥ 6 ثوانٍ (MIN_SLATE_GAP_MS = 6000).

الحد ليس عشوائيًا. يفرض MediaLive تباعدًا لا يقل عن 5 ثوانٍ بين أي إجراءين مجدولين؛ يؤدي إصدار إجراء تبديل slate أقرب من ذلك إلى إجراء تبديل المدخل للبرنامج التالي إلى رفض. تمنح قاعدة 6 ثوانٍ MediaLive الفجوة المطلوبة وتترك طبقة التنسيق هامش أمان زمني لثانية واحدة. تحت 6 ثوانٍ، نترك الإطار الأخير للبرنامج السابق يتجمد لفترة وجيزة بدلاً من المخاطرة برفض النشر.

4. العلامة المائية لكل نسخة مع تأخير تفعيل محسوب

العلامة المائية هي إجراء StaticImageOutputActivate يصدر لكل نسخة إخراج (1080p، 720p، 480p، 360p) — أربعة إجراءات لكل برنامج. يتم تشغيل كل إجراء 1,500 مللي ثانية بعد تبديل المدخل لذلك البرنامج.

يوجد التأخير لأن الإطارات الأولى بعد تبديل المدخل لا تزال في وضع التخزين المؤقت؛ يمكن أن يؤدي تفعيل التراكب في لحظة التبديل بالضبط إلى وميض قصير حيث يتم رسم التراكب على إطار لم يتم عرضه بالكامل بعد. كانت 1,500 مللي ثانية هي القيمة التي أنتجت تفعيلًا نظيفًا باستمرار عبر جميع النسخ الأربع في الاختبار. إنه ثابت مقاس، وليس معلمة موثقة من MediaLive — ويعيش في مكان واحد في الكود بحيث يكون ضبطه في المستقبل تغييرًا في سطر واحد.

المقايضة التي قمنا بها عن قصد. إجراءات التراكب لكل نسخة تكلف 4× عدد الإجراءات مقابل تراكب عالمي واحد. نقبل التكلفة لأن المسار لكل نسخة يسمح لكل إخراج بالحصول على علامة مائية بحجم يناسب أبعاد البكسل الخاصة به، بدلاً من السماح لـ MediaLive بتقليص تراكب واحد عبر الأربعة جميعًا. النتيجة هي شعار أكثر وضوحًا على مخرجات SD — ويترك ميزانية الإجراءات كافية لمئات البرامج قبل أن يصبح حد 1500 مهمًا.

5. سقف 1500 إجراء، تم التحقق منه مسبقًا في واجهة المستخدم

AWS يحدد بصرامة قناة MediaLive عند 1500 إجراء جدولي. مع ~7-8 إجراءات لكل برنامج (تبديل المدخل + 4 علامات مائية + 2 إشارات إعلانات + slate عرضي)، تحتوي القناة على حوالي 180-200 برنامج نشط اعتمادًا على كثافة الإعلانات وتكرار slate. هذا سقف حقيقي لعمليات النشر طويلة الأفق، والعدد الدقيق يعتمد على تعقيد كل برنامج.

قبل كل نشر، يستدعي الخلفية GET_SCHEDULE_COUNT من Lambda، الذي يحصي الإجراءات الحية على القناة عبر DescribeScheduleCommand ويعيد { liveCount, capacity: 1500 }. إذا كان liveCount + (newPrograms × 8) سيتجاوز 1500، يقوم الخلفية بإلقاء SCHEDULE_ACTION_CAP_EXCEEDED مع الرقم الدقيق للمساحة المتاحة — قبل أن يقدم أي شيء إلى MediaLive. يرى المشغل الحد في واجهة المستخدم مع إرشادات لمسح البرامج السابقة أولاً. لا ينفذ النشر نصفه في الجدار.

الرسم البياني 3 · الجدول الزمني لإجراءات برنامج واحد

النتائج

• تخدم قناة MediaLive واحدة برامج فريدة غير محدودة فعليًا على مدار عمرها، على مرفق إدخال ديناميكي واحد. لم يعد حد 20 إدخالًا قيدًا يجب التخطيط له — السعة في أي وقت واحد تحكمها حد الإجراءات الجدولية، وليس حد الإدخال.
• تنسيق القناة ذاتي الشفاء: ينتهي كل نشر بمسح الأيتام، لذا لا يمكن للفشل الجزئي في النشر أن يترك الجدول الزمني في حالة غير متسقة.
• سعة الجدول الزمني محدودة ومرئية. يرى المشغلون سقف 1500 إجراء في واجهة المستخدم قبل النقر، وليس كرفض AWS غامض في منتصف النشر.
• تقليد التسمية بمعرف البرنامج هو طبقة الهوية بأكملها — وهي سلسلة. لا بنية تحتية جديدة، لا تخزين إضافي، لا تبعيات. الإسقاط الأبسط الممكن لـ "البرنامج" على قائمة الإجراءات المسطحة لـ MediaLive.

التقنية المستخدمة: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)