شعار قناة FAST — العلامة الصغيرة في الزاوية — هو الثابت البصري الوحيد عبر كل برنامج، وكل فاصل إعلاني، وكل شاشة تعرضها القناة. يجب أن يبدو احترافيًا عند كل مستوى جودة قد يتلقاه المشاهد. النهج الساذج — تحميل صورة رئيسية واحدة وترك AWS MediaLive يقوم بتغيير حجمها لكل عرض — ينتج شعارًا حادًا عند 1080p وآخر ناعمًا بشكل واضح عند 360p. هذه مشكلة علامة تجارية لكل مشاهد لا يستخدم النطاق العريض. إليك كيف قمنا بتغيير حجم الشعار ليناسب شبكة البكسل الدقيقة لكل عرض بدلاً من ذلك.
نظرة عامة سريعة
| الجانب | التفاصيل |
|---|---|
| النطاق | تراكب شعار القناة (DOG) على قنوات FAST |
| الآلية | `StaticImageOutputActivate` لكل إخراج لكل عرض (1080p, 720p, 480p, 360p) |
| توليد الأصول | سكربت Python باستخدام إعادة التعيين Lanczos |
| توقيت التفعيل | 1.5 ثانية بعد تبديل إدخال كل برنامج |
| الحالة | مكدس 1× لكل عرض في الإنتاج |
المشكلة التجارية
لا تقدم قناة FAST مستوى جودة واحدًا. يقوم MediaLive بترميز نفس القناة إلى عروض متعددة — 1080p و 720p و 480p و 360p — ويختار مشغل كل مشاهد الأفضل الذي يمكن أن يدعمه اتصاله. يشاهد مستخدمو الجوال على بيانات الجوال 360p؛ ويحصل مستخدمو التلفزيونات الذكية على النطاق العريض على 1080p. جميعهم ينظرون إلى نفس العلامة التجارية، وجميعهم يتوقعون أن تبدو احترافية. عندما يكون الشعار واضحًا عند 1080p وناعمًا بشكل واضح عند 360p، تكون العلامة التجارية غير متناسقة — وهذا ليس تفصيلاً ثانويًا على قناة تعمل 24/7 حيث يكون الشعار هو العنصر الوحيد الذي يراه المشاهدون أكثر من أي برنامج فردي.
أين يتم تطبيق التراكبات بالفعل
في مسار عمل المشفر متعدد العروض، يمكن تطبيق التراكب في مكانين:
قبل مقياس كل عرض، حيث يتم دمج صورة رئيسية واحدة على المصدر ويتم تصغير الحجم الكلي لكل إخراج — وهذا ما يفعله MediaLive بإجراء `StaticImageActivate` عام
بعد المقياس، حيث يحصل كل إخراج على تراكبه الخاص المطبق بمجرد أن تكون اللوحة بالحجم النهائي. يبدو الفرق صغيرًا في API. بصريًا، ليس كذلك. أي شيء يتم دمجه قبل المقياس يرث كل التشوهات التي يقدمها المقياس، وعند 360p، يكون المقياس عدوانيًا.

لماذا تفشل الحلول الواضحة
"قم بتحميل صورة رئيسية واحدة ودع MediaLive يقوم بتغيير حجمها." يقوم الإجراء العام بدمج الصورة الرئيسية قبل تشغيل مقياس كل إخراج. تقليل حجم صورة رئيسية كبيرة إلى شعار بحجم 64×21 بكسل لـ 360p هو تقليل بمقدار 40x تقريبًا — حتى إعادة التعيين Lanczos تفقد التفاصيل الدقيقة بهذه النسبة، ثم تمر النتيجة عبر نفس سلسلة الضغط مثل الفيديو نفسه.
"استخدم صورة رئيسية أكبر." هذا يجعل نسبة التصغير أكبر، وليس أصغر — تزداد التشوهات سوءًا، ولا تتحسن.
"تجاوز الشعار في إخراجات SD." تتطلب متطلبات الامتثال والعلامة التجارية وجود العلامة على كل عرض. ليس خيارًا.
"حرق الشعار في الفيديو المصدر وقت الترميز." يفقد كل رافعة تشغيلية — لا تغييرات في الشعار حسب الحملة أو المنطقة، ولا تحديث بدون إعادة ترميز المكتبة بأكملها.
"استخدام تراكب عام بإحداثيات يدوية لكل دقة." يحسب الإجراء العام الموضع مقابل مرجع ثابت 1920×1080، لذا فإن مقاطع الفيديو المصدر الأضيق من ذلك تنتج إحداثيات خارج اللوحة — ينجرف الشعار بعيدًا عن الزاوية أو يتم قصه.
كانت الرافعة الحقيقية هي تجاوز تحجيم تراكب MediaLive بالكامل: تغيير حجم الشعار ليلائم لوحة كل عرض بأنفسنا، قبل أن يلمسه المشفر على الإطلاق.
الحل
يتم عرض شعار كل عرض مسبقًا بأبعاده البكسلية الدقيقة وتخزينه كملف PNG منفصل. عند كل حدود برنامج، يقوم منسق Lambda بإطلاق أربعة إجراءات `StaticImageOutputActivate` — واحد لكل عرض — يشير كل منها إلى ملف PNG الذي تم تغيير حجمه بالفعل لهذا الإخراج المحدد. لا يقوم MediaLive بأي تغيير للحجم على التراكب.
عام (ساذج) لكل إخراج (ما نرسله)
master.png ──► دمج على master.png ──► تغيير حجم Lanczos (غير متصل)
لوحة المصدر إلى 4 ملفات PNG بالحجم الدقيق
│ │
▼ ▼
مقياس لكل عرض مقياس لكل عرض
(يغير أيضًا حجم (التراكب لا يتم لمسه —
التراكب ← شعار ناعم يتم دمجه بعد ذلك، بحجم
على إخراجات SD) البكسل الدقيق)يقوم سكربت Python بتوليد ملفات PNG الأربعة ذات الأحجام المحددة من صورة رئيسية واحدة باستخدام إعادة التعيين Lanczos، والذي تم اختياره لسلوكه المتوقع والقابل للتكرار عند الأحجام الصغيرة بدلاً من الفوز بمسابقة جودة البكسل. يهبط كل شعار بنسبة 10% تقريبًا من عرض لوحته — مرئي دون أن يكون متطفلاً — وتكون إضافة عرض جديد هي مجرد إدخال صفيف واحد بالإضافة إلى ملف PNG جديد.
قرارات رئيسية تستحق الذكر
تأخير التفعيل بمقدار 1.5 ثانية. يتم تشغيل إجراءات تفعيل العلامة المائية بعد 1.5 ثانية من كل تبديل إدخال، وليس في لحظة التبديل بالضبط — التفعيل الفوري يمكن أن يسبب وميضًا مقابل الإطارات غير المستقرة بعد. تم ضبط القيمة تجريبيًا وتم مركزتها كقيمة ثابتة واحدة بحيث يكون الضبط المستقبلي تغييرًا في سطر واحد.
توليد الأصول غير المتصل بالإنترنت، الذي يتم تشغيله يدويًا — عمدًا. مسار عمل تغيير الحجم Lanczos ليس مؤتمتًا كخطوة بناء أو تحويل من جانب CDN. تتغير أصول الشعار نادرًا بما يكفي ليكون التجديد بأمر واحد هو المقدار المناسب من الأتمتة؛ وتفوق تكلفة بناء المزيد من الأتمتة تكلفة تشغيل سكربت مرتين في السنة.
نسخة "سميكة" موجودة ولكن لا يتم شحنها. ينتج المولد أيضًا نسخة dilated-alpha بضربات سميكة، مخصصة لتحمل H.264 quantization بمعدلات بت منخفضة SD. إنها ليست في الإنتاج — النسخة القياسية كافية لنطاق معدل البت الحالي، ولا يوجد قياس حتى الآن يبرر التبديل. إنها موجودة كنسخة احتياطية تم اختبارها بالرمز: رخيصة لإبقائها متاحة، ومن السابق لأوانه شحنها.
ما نراقبه حاليًا
لا يكتمل أي مسار عمل إنتاج فيديو بشكل حقيقي أبدًا، ولا تزال هناك فرص لتحسين هذا النهج بمرور الوقت.
يضمن التنفيذ الحالي أن يتلقى كل عرض شعارًا معدًا خصيصًا لدقة إخراجه، مما يلغي تغيير حجم التراكب في وقت التشغيل من مسار عمل MediaLive. ومع ذلك، لا يزال المظهر النهائي محدودًا بشكل طبيعي بدقة كل عرض وضغط الفيديو، خاصة عند معدلات البت المنخفضة. مع تطور ملفات تعريف البث، سنستمر في تقييم ما إذا كانت معالجات الشعار المختلفة توفر فوائد بصرية قابلة للقياس في تلك الظروف.
يدعم مولد الأصول بالفعل كلاً من الشعار القياسي والنسخة الأكثر سمكًا. إذا أظهرت الاختبارات المستقبلية أن النسخة الأكثر سمكًا تعمل بشكل أفضل للعروض ذات معدلات البت المنخفضة، فسنقوم بجعل اختيار نسخة الشعار يعتمد على التكوين بحيث يمكن تغييره دون إعادة نشر التطبيق.
النتائج
يتلقى كل عرض الآن شعارًا بحجم مخصص للوحته الخاصة، مع قيام MediaLive بتنفيذ صفر تحجيم تراكب في وقت التشغيل. يستخدم كل إخراج عملًا فنيًا مُعدًا لدقة الهدف، متجنبًا التليين الإضافي الذي يسببه تحجيم التراكب في وقت التشغيل مع الحفاظ على أفضل جودة بصرية عملية يمكن أن يقدمها العرض.
تم التخلص من خطأ انحراف الإحداثيات من نهج التراكب العالمي السابق، حيث يمكن أن تتحرك الشعارات على مقاطع الفيديو المصدر الأضيق من 1920 بكسل، بشكل هيكلي لأن التفعيل لكل إخراج يعمل بالكامل في إحداثيات الإخراج.
أصبح استبدال الشعار الآن مهمة تشغيلية بسيطة: إعادة إنشاء الأصول الخاصة بالعرض باستخدام سكربت واحد وتحميلها. لا يلزم إعادة ترميز الفيديو ولا التحرير اليدوي لكل عرض.
يتبع هذا التنفيذ مبدأ هندسيًا بسيطًا: حل المشكلات في أقرب وقت ممكن في مسار العمل، والتصميم حول إمكانيات المنصة بدلاً من الاعتماد على حلول بديلة لاحقة. من خلال إعداد الأصل الصحيح قبل الترميز، يظل مسار العمل المباشر أبسط وأكثر قابلية للتنبؤ وأسهل في الصيانة.
إذا كنت تواجه مشكلات مماثلة في جودة العرض أو التراكب على مسار عمل فيديو مباشر، تواصل معنا.
حزمة التقنيات: AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)

