دليل مشغل الوسائط المتدفق OEM/ODM

دليل OEM/ODM لمشغل الوسائط المتدفقة: من اللوحة المرجعية إلى المنتج القابل للتطوير

يعمل فك تشفير AV1، وخطوط أنابيب الفيديو عالية الدقة، وWi-Fi 6، وGigabit Ethernet، وأنظمة ARM SoC ذات القدرة المتزايدة على رفع خط الأساس لأجهزة البث التجارية. ولكن بالنسبة لمشروع OEM/ODM، فإن دعم برنامج الترميز هو نقطة البداية فقط.

من الممكن أن يفشل مشغل الوسائط المتدفقة الذي يعمل بشكل جيد في المختبر تجاريًا بسبب الاختناق الحراري، أو عدم استقرار BSP، أو عدم كفاية ذاكرة الوصول العشوائي (RAM)، أو ضعف استرداد OTA، أو متطلبات إدارة الحقوق الرقمية (DRM) غير المتوافقة، أو ضعف الدعم الطرفي، أو البرامج الثابتة التي لا يمكنها استيعاب البرامج الوسيطة للعميل.

وبالتالي فإن برنامج OEM/ODM الناجح يبدأ ببنية النظام، وليس بصندوق البيع بالتجزئة النهائي.

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

ما الذي يجب تخصيصه في مشروع OEM/ODM لمشغل الوسائط المتدفقة؟

الخطأ الأول في مشروع OEM هو التعامل مع التخصيص كطباعة شعار وتغييرات في الغلاف.

يمكن أن يتضمن برنامج Streaming Media Player OEM/ODM الجاد تغييرات على خمسة مستويات:

1. بنية SoC و PCBA

2. الذاكرة والتخزين والاتصال والواجهات

3. أندرويد/لينكس BSP والنواة

4. إطار التطبيق وواجهة المستخدم/تجربة المستخدم

5. التصنيع، وOTA، والأمن، وإدارة دورة الحياة

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

1. تخصيص PCBA وSOC

يجب أن يتبع اختيار SoC عبء عمل التطبيق.

النظام الأساسي المخصص لتشغيل 4K OTT له متطلبات مختلفة عن التعامل مع اللافتات الرقمية متعددة الشاشات، أو استدلال الذكاء الاصطناعي، أو تطبيقات الضيافة، أو معالجة الوسائط الصناعية.

يجب أن يشمل التقييم ما يلي:

• بنية وحدة المعالجة المركزية والأداء المستدام

• قدرة GPU

• وحدة فك ترميز الفيديو وكتل التشفير

• دعم AV1 وH.265/HEVC وVP9

• HDR وخط أنابيب العرض

• قدرة إخراج HDMI

• عرض النطاق الترددي والسعة RAM

• eMMC أو خيارات التخزين الأخرى

• وحدة تحكم إيثرنت

• شريحة واي فاي/بلوتوث

• واجهات USB والتسلسلية

• متطلبات GPIO

• بنية إدارة الطاقة

• الخصائص الحرارية

يصبح تعديل PCBA ضروريًا عندما لا يتطابق التصميم المرجعي القياسي مع النشر.

على سبيل المثال، قد يحتاج عميل OEM إلى منافذ USB إضافية، أو Gigabit Ethernet، أو وحدة لاسلكية مختلفة، أو RS-232، أو GPIO مخصص، أو مساحة تخزين أكبر، أو دائرة طاقة معدلة، أو تكوين موصل مختلف.

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

2. الهندسة الحرارية للتشغيل المستمر

غالبًا ما يتم تصميم أجهزة البث الاستهلاكي بحيث تتلاءم مع الاستخدام السكني المتقطع. يمكن للمعدات التجارية أن تعمل بشكل مستمر لفترات طويلة.

هذا يغير متطلبات التصميم الحراري.

قد يحتاج مشغل الوسائط المتدفقة OEM إلى دعم فك تشفير 4K المستدام، أو حركة مرور الشبكة، أو الوصول إلى التخزين المحلي، أو تشغيل الإعلانات، أو استدلال الذكاء الاصطناعي، أو تطبيقات متعددة أثناء التشغيل داخل مساحة تثبيت محدودة.

يمكن لـ SZTomato تخصيص حلول تبريد متخصصة بناءً على عبء العمل المستهدف، بما في ذلك أبعاد المبدد الحراري، والواجهات الحرارية، ووضع المكونات، ومسارات تبديد الحرارة، وتدفق الهواء في العلبة.

الهدف ليس مجرد انخفاض درجة حرارة السطح. الهدف الهندسي هو أداء SoC مستقر دون الاختناق الحراري غير الضروري.

يجب أن يقوم برنامج التحقق العملي بقياس:

• درجة حرارة شركة نفط الجنوب تحت الحمل المستمر

• استخدام وحدة المعالجة المركزية/وحدة معالجة الرسومات

• استخدام وحدة فك ترميز الفيديو

• سلوك الاختناق الحراري

• استهلاك الطاقة

• أداء درجة الحرارة المحيطة

• استقرار التشغيل لفترة طويلة

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

كيفية بناء بنية البرامج الثابتة

يؤدي تخصيص الأجهزة إلى إنشاء النظام الأساسي. يحدد تخصيص البرامج الثابتة ما إذا كانت المنصة تناسب بالفعل النظام البيئي للعميل.

نادرًا ما تكون صورة المستهلك القياسية كافية لنشر OEM على نطاق واسع.

أندرويد أم AOSP أم لينكس؟

يجب اختيار نظام التشغيل حسب التطبيق.

يمكن أن يكون Android TV مناسبًا عندما يتطلب المشروع تجربة مستخدم موجهة نحو التلفزيون ونظامًا بيئيًا متوافقًا للتطبيقات.

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

يمكن أن يكون Linux أو Debian أو Ubuntu مفضلاً للتطبيقات الصناعية أو حوسبة الحافة أو اللافتات الرقمية أو البرامج الوسيطة المتخصصة أو المشاريع التي يكون فيها التحكم في النظام على مستوى Linux أولوية.

العامل المهم ليس نظام التشغيل المألوف. يتعلق الأمر بما إذا كان يمكن الحفاظ على BSP والنواة وبرامج التشغيل والبرامج الوسيطة والتطبيقات وآلية التحديث وواجهات الأجهزة كبنية منتج واحدة.

تحسين Linux/Android Kernel

تصبح طبقة النواة مهمة عندما لا يوفر SDK/BSP القياسي السلوك المطلوب.

اعتمادا على المشروع، قد تشمل الهندسة ما يلي:

• برامج تشغيل إيثرنت وواي فاي

• تكوين USB

• سلوك العرض وHDMI

• واجهات الصوت

• جيبيو

• التواصل التسلسلي

• إدارة الطاقة

• السياسات الحرارية

• تكوين التخزين

• تحسين التمهيد

• أذونات النظام

• تسريع الأجهزة

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

لم يتم تحسين الجهاز الذي يتم تشغيله بسرعة ولكنه يفقد الاتصال بالشبكة بعد التشغيل الممتد. المشغل الذي يقوم بفك تشفير فيديو 4K ولكن ترتفع درجة حرارته بعد عدة ساعات لم يتم تحسينه أيضًا.

الهدف هو سلوك النظام الذي يمكن التنبؤ به في ظل عبء العمل الفعلي.

واجهة المستخدم/تجربة المستخدم المخصصة وطبقة التطبيق

تعد واجهة المستخدم نقطة تمايز رئيسية أخرى لتصنيع المعدات الأصلية.

يمكن للمشغل المخصص أن يحل محل شاشة Android الرئيسية القياسية ببيئة يتحكم فيها المشغل وتحتوي على:

• هوية العلامة التجارية

• التنقل المخصص

• اختصارات الخدمة

• المحتوى الموصى به

• مناطق إعلانية

• خدمات الضيافة

• ضوابط اللافتات الرقمية

• تقييد الوصول إلى النظام

بالنسبة للتطبيقات المُدارة، يمكن لواجهات برمجة تطبيقات مالك الجهاز وآليات مهمة الكشك/القفل تقييد وصول المستخدم إلى التطبيقات المعتمدة ووظائف النظام.

وهذا مهم بشكل خاص لأنظمة تلفزيون الفنادق، وشاشات العرض التجارية، وخدمات IPTV، وعمليات نشر التعليم، والمحطات الطرفية المواجهة للعامة.

تكامل SDK/API: توصيل المشغل بنظام الأعمال

يصبح مشغل الوسائط المتدفقة أكثر قيمة بشكل كبير عندما يتكامل مع البنية التحتية الحالية للعميل.

قد يحتاج مورد OEM/ODM إلى الكشف عن واجهات برمجة التطبيقات أو دمجها من أجل:

• الوسيطة IPTV

• منصات OTT

• منصات نظام إدارة المحتوى

• أنظمة اللافتات الرقمية

• إدارة المشتركين

• أنظمة الإعلان

• منصات التحليلات

• توفير الجهاز

• المراقبة عن بعد

• إدارة المحتوى

• مصادقة المؤسسة

هذا هو المكان الذي يصبح فيه تكامل SDK/API أكثر أهمية من العلبة المادية.

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

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

أنظمة تحديث OTA والتحكم في المنتج على المدى الطويل

يجب على مشتري OEM تقييم دورة حياة البرنامج الثابت قبل التوقيع على اتفاقية الإنتاج.

قد يتم شحن المنتج مزودًا بأجهزة ممتازة ويصبح تشغيله مكلفًا إذا كانت تحديثات البرامج الثابتة تتطلب صيانة يدوية.

يجب أن تعالج بنية OTA القوية ما يلي:

• إدارة إصدار البرامج الثابتة

• تحديثات تزايدية أو كاملة للصورة

• مجموعات الأجهزة

• النشر المرحلي

• سياسات التحديث التلقائي

• تحديث التحقق

• فشل استرداد التحديث

• التراجع

• التشخيص عن بعد

• تحديثات التطبيق

• إدارة التكوين

بالنسبة لعمليات النشر الكبيرة، يعتبر نشر OTA على مراحل أمرًا مهمًا بشكل خاص.

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

وهذا يقلل من خطر حدوث خلل واحد في البرنامج الثابت مما يؤثر على القاعدة المثبتة بأكملها.

يجب تصميم الأمان وDRM وHDCP في النظام الأساسي

تعمل أجهزة البث بشكل متزايد ضمن الأنظمة البيئية للمحتوى المحمي.

اعتمادًا على متطلبات الخدمة وموفر المحتوى، قد يحتاج النظام الأساسي إلى دعم أطر إدارة الحقوق الرقمية (DRM)، والتمهيد الآمن، والاتصالات المشفرة، ومصادقة التطبيقات، ومخرج HDMI المحمي بتقنية HDCP، ووظائف الأمان المدعومة بالأجهزة.

يجب تحديد متطلبات DRM وHDCP قبل الانتهاء من بنية SoC والبرامج الثابتة.

يعد هذا أحد الاعتبارات المهمة لـ OEM نظرًا لأن إمكانات الأمان ليست قابلة للتبديل دائمًا بين مجموعات الشرائح. لا يمكن لتعديل البرنامج أن يعوض النظام الأساسي للأجهزة الذي يفتقر إلى ميزة الأمان المطلوبة.

بالنسبة لعمليات النشر التجارية، يجب على الفريق الهندسي تحديد متطلبات حماية المحتوى في بداية المشروع.

عملية تطوير مشغل الوسائط المتدفقة OEM/ODM

يجب أن يتبع برنامج OEM الذي يتم التحكم فيه تسلسلًا هندسيًا محددًا.

المرحلة الأولى: تعريف المتطلبات

وثيقة:

• السوق المستهدف

• سيناريو التطبيق

• دقة الفيديو

• برامج الترميز المطلوبة

• واجهات العرض

• واجهات الشبكة

• نظام التشغيل

• ذاكرة الوصول العشوائي/التخزين

• متطلبات التطبيق

• متطلبات إدارة الحقوق الرقمية

• متطلبات OTA

• الظروف البيئية

• حجم الإنتاج المستهدف

تصبح هذه الوثيقة الأساس لاختيار النظام الأساسي.

المرحلة 2: اختيار النظام الأساسي وPCBA

حدد SoC والبنية المرجعية وفقًا لحجم العمل.

ثم حدد المكونات التي يمكن أن تظل قياسية والمكونات التي تتطلب التعديل.

وهذا يقلل من NRE غير الضروري ويتجنب إعادة تصميم الأجزاء الثابتة من النظام الأساسي دون سبب تجاري.

المرحلة 3: تطوير البرامج الثابتة وSDK

قم ببناء BSP المطلوب، وتكوين kernel، وبرامج التشغيل، وخدمات النظام، والتطبيقات، والمشغل، وUI/UX، وواجهات برمجة التطبيقات، وإطار عمل OTA.

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

المرحلة 4: EVT وDVT والتحقق من صحة الإنتاج

يجب أن يحدد اختبار التحقق من الصحة مشاكل الأجهزة والبرامج الثابتة مبكرًا.

يجب أن يتحقق اختبار التحقق من صحة التصميم من المنتج الكامل في ظل ظروف التشغيل المتوقعة.

يجب أن يشمل الاختبار ما يلي:

• تشغيل الفيديو لمدة طويلة

• انقطاع الشبكة والانتعاش

• سلوك التوصيل السريع لـ HDMI

• استقرار الواي فاي

• إنتاجية إيثرنت

• استعادة انقطاع OTA

• اختبار دورة الطاقة

• الإجهاد الحراري

• موثوقية التخزين

• استقرار التطبيق

• وظائف الإدارة عن بعد

فقط بعد التحقق من صحة هذه المناطق يجب أن يتحرك المشروع نحو الإنتاج الضخم.

لماذا تعد القدرة الهندسية لـ OEM/ODM أكثر أهمية من مواصفات الصندوق

يمكن لمشغلي وسائط متدفقة استخدام نفس شركة نفط الجنوب وتقديم نتائج تجارية مختلفة تمامًا.

الفرق غالبا ما يأتي من التنفيذ.

تخطيط ثنائي الفينيل متعدد الكلور، واختيار الذاكرة، والتصميم الحراري، وتنظيم الطاقة، وجودة BSP، وتكوين kernel، واستقرار برنامج التشغيل، وبنية المشغل، وتكامل التطبيقات، وتصميم OTA، وجودة التصنيع، كلها تؤثر على المنتج النهائي.

ولهذا السبب يجب على فرق المشتريات تقييم مورد OEM/ODM على المستوى الهندسي.

يعتمد نهج SZTomato على التحكم في هذه الطبقات بدلاً من التعامل مع OEM كخدمة تخصيص تجميلية. تغطي قدراتها تعديل أجهزة PCBA، وتطوير منصة SoC، والبرامج الثابتة المخصصة، وتحسين Android/Linux، وتكامل SDK/API، وUI/UX المخصص، وأنظمة OTA، والحلول الحرارية المتخصصة.

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

ويمكن تكييف نفس البنية لمشغلي IPTV، ومقدمي خدمات OTT، ومشاريع الاتصالات، ومجموعات الضيافة، وشركات اللافتات الرقمية، ومتكاملي الأنظمة، والتطبيقات الصناعية.

قائمة مراجعة OEM/ODM لمديري المشتريات B2B

قبل اختيار الشركة المصنعة لـ Streaming Media Player، اطرح الأسئلة التالية:

الأجهزة

• هل يمكن تعديل PCBA؟

• هل يمكن تخصيص تكوينات ذاكرة الوصول العشوائي والتخزين؟

• هل يمكن تغيير Ethernet أو Wi-Fi أو USB أو RS-232 أو GPIO أو واجهات أخرى؟

• هل تتحكم الشركة المصنعة في التصميم الحراري؟

البرامج الثابتة

• هل يمكن تخصيص البرامج الثابتة لنظام Android/AOSP/Linux؟

• هل يمكن تعديل نواة Linux/Android؟

• هل يمكن تغيير عملية التمهيد وخدمات النظام؟

• هل يمكن تطوير قاذفة مخصصة وواجهة المستخدم/تجربة المستخدم؟

اندماج

• هل يمكن للمورد دمج SDKs وAPIs؟

• هل يمكن تنفيذ وظائف مالك الجهاز والكشك؟

• هل يمكن دمج منصات البرمجيات الوسيطة وأنظمة إدارة المحتوى (CMS)؟

• هل يمكن دعم أنظمة الإدارة عن بعد؟

الأمن ودورة الحياة

• ما هي متطلبات DRM وHDCP التي يمكن للنظام الأساسي دعمها؟

• هل البنية التحتية لتحديث OTA متاحة؟

• هل التراجع مدعوم؟

• كيف يتم التحكم في إصدارات البرامج الثابتة الخاصة بالإنتاج؟

• من يحافظ على BSP بعد الإنتاج الضخم؟

تصنيع

• هل هناك فريق هندسي خلف المصنع؟

• هل يمكن إجراء اختبار EVT/DVT؟

• هل يمكن للمورد دعم NRE والأدوات؟

• هل يمكن الحفاظ على نفس تكوين الأجهزة والبرامج الثابتة على نطاق واسع؟

تفصل هذه الأسئلة بين برنامج OEM/ODM الأصلي وبين عملية الشراء ذات العلامة الخاصة.

الخلاصة: اختر شريكًا هندسيًا، وليس مجرد مورد أجهزة

أ مشغل الوسائط المتدفقة ينجح مشروع OEM/ODM عندما يتم تصميم الأجهزة والبرامج الثابتة وتكامل البرامج والتصميم الحراري والأمان والتصنيع كنظام واحد.

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

بالنسبة لمديري المشتريات في مجال B2B ومتكاملي الأنظمة، يجب أن تكون الخطوة التالية هي مراجعة المتطلبات الفنية التي تغطي SoC وPCBA ونظام التشغيل والواجهات والبرامج الثابتة وتكامل UI/UX وSDK/API وDRM/HDCP والظروف الحرارية وبنية OTA وحجم الإنتاج.

إذا كان المشروع يتطلب أكثر من شعار وعلبة كرتونية مخصصة، فاختر شركة تصنيع OEM/ODM تتمتع بالقدرة الهندسية لتعديل النظام الأساسي على مستويات الأجهزة والنواة والبرامج الثابتة والتطبيقات.

توفر SZTomato مشغل الوسائط المتدفقة تطوير OEM/ODM للشركات التي تحتاج إلى نظام أساسي قابل للتكوين مصمم خصيصًا لمتطلبات الخدمة والبرمجيات الوسيطة والنشر الخاصة بها.