คู่มือ OEM/ODM ของเครื่องเล่นมีเดียสตรีมมิ่ง

คู่มือ OEM/ODM ของ Streaming Media Player: จากบอร์ดอ้างอิงไปจนถึงผลิตภัณฑ์ที่ปรับขนาดได้

การถอดรหัส AV1, ไปป์ไลน์วิดีโอความละเอียดสูงกว่า, Wi-Fi 6, Gigabit Ethernet และ ARM SoC ที่มีความสามารถมากขึ้นกำลังยกระดับพื้นฐานสำหรับฮาร์ดแวร์การสตรีมเชิงพาณิชย์ แต่สำหรับโครงการ OEM/ODM การสนับสนุนตัวแปลงสัญญาณเป็นเพียงจุดเริ่มต้นเท่านั้น

Streaming Media Player ที่ทำงานได้ดีในห้องปฏิบัติการยังคงล้มเหลวในเชิงพาณิชย์ได้เนื่องจากการควบคุมปริมาณความร้อน, BSP ที่ไม่เสถียร, RAM ไม่เพียงพอ, การกู้คืน OTA ที่ไม่ดี, ข้อกำหนด DRM ที่เข้ากันไม่ได้, การรองรับอุปกรณ์ต่อพ่วงที่อ่อนแอ หรือเฟิร์มแวร์ที่ไม่สามารถรองรับมิดเดิลแวร์ของลูกค้าได้

โปรแกรม OEM/ODM ที่ประสบความสำเร็จจึงเริ่มต้นด้วยสถาปัตยกรรมระบบ ไม่ใช่กล่องขายปลีกสำเร็จรูป

สำหรับผู้ซื้อ B2B วัตถุประสงค์คือการเปลี่ยนแพลตฟอร์มอ้างอิงให้เป็นผลิตภัณฑ์ที่มีการควบคุม มีแบรนด์ และบำรุงรักษาได้ ด้วยฮาร์ดแวร์ เฟิร์มแวร์ ซอฟต์แวร์ คุณลักษณะด้านความร้อน การเชื่อมต่อ และการสนับสนุนวงจรชีวิตที่จำเป็น

สิ่งที่ควรปรับแต่งในโครงการ OEM/ODM ของ Streaming Media Player

ข้อผิดพลาดแรกในโครงการ OEM คือการปรับแต่งตามการพิมพ์โลโก้และการเปลี่ยนแปลงกล่องหุ้ม

โปรแกรม OEM/ODM Streaming Media Player ที่จริงจังสามารถเกี่ยวข้องกับการเปลี่ยนแปลงได้ห้าระดับ:

1. สถาปัตยกรรม SoC และ PCBA

2. หน่วยความจำ อุปกรณ์จัดเก็บข้อมูล การเชื่อมต่อ และอินเทอร์เฟซ

3. Android/Linux BSP และเคอร์เนล

4. กรอบงานแอปพลิเคชันและ UI/UX

5. การผลิต, OTA, ความปลอดภัย และการจัดการวงจรชีวิต

ยิ่งการปรับแต่งที่จำเป็นลึกซึ้งยิ่งขึ้น การทำงานร่วมกับผู้ผลิตที่ควบคุมวิศวกรรมฮาร์ดแวร์และเฟิร์มแวร์ก็ยิ่งมีความสำคัญมากขึ้น แทนที่จะเพียงแต่จัดหากล่องสำเร็จรูปเท่านั้น

1. การปรับแต่ง PCBA และ SoC

การเลือก SoC ควรเป็นไปตามปริมาณงานของแอปพลิเคชัน

แพลตฟอร์มที่มีไว้สำหรับการเล่น 4K OTT มีข้อกำหนดที่แตกต่างจากการจัดการป้ายดิจิทัลหลายหน้าจอ การอนุมาน AI แอปพลิเคชันการต้อนรับ หรือการประมวลผลสื่ออุตสาหกรรม

การประเมินควรรวมถึง:

• สถาปัตยกรรม CPU และประสิทธิภาพที่ยั่งยืน

• ความสามารถของ GPU

• ตัวถอดรหัสวิดีโอและบล็อกตัวเข้ารหัส

• รองรับ AV1, H.265/HEVC และ VP9

• HDR และไปป์ไลน์การแสดงผล

• ความสามารถในการส่งสัญญาณ HDMI

• แบนด์วิดธ์ RAM และความจุ

• eMMC หรือตัวเลือกการจัดเก็บข้อมูลอื่น ๆ

• ตัวควบคุมอีเทอร์เน็ต

• ชิปเซ็ต Wi-Fi/บลูทูธ

• อินเทอร์เฟซ USB และอนุกรม

• ข้อกำหนด GPIO

• สถาปัตยกรรมการจัดการพลังงาน

• ลักษณะทางความร้อน

การปรับเปลี่ยน PCBA กลายเป็นสิ่งจำเป็นเมื่อการออกแบบอ้างอิงมาตรฐานไม่ตรงกับการใช้งาน

ตัวอย่างเช่น ลูกค้า OEM อาจต้องการพอร์ต USB เพิ่มเติม, Gigabit Ethernet, โมดูลไร้สายอื่น, RS-232, GPIO แบบกำหนดเอง, พื้นที่จัดเก็บข้อมูลที่เพิ่มขึ้น, วงจรไฟฟ้าที่ได้รับการแก้ไข หรือการกำหนดค่าตัวเชื่อมต่ออื่น

การเปลี่ยนแปลงเหล่านี้ส่งผลต่อโครงร่าง PCBA ความสมบูรณ์ของสัญญาณ การกระจายพลังงาน ประสิทธิภาพของ EMI เส้นทางระบายความร้อน และการออกแบบกล่องหุ้ม ควรได้รับการออกแบบทางวิศวกรรมร่วมกันแทนที่จะถือเป็นการดัดแปลงโดยอิสระ

2. วิศวกรรมความร้อนเพื่อการทำงานต่อเนื่อง

อุปกรณ์สตรีมมิ่งสำหรับผู้บริโภคมักได้รับการออกแบบให้เหมาะกับการใช้งานในที่พักอาศัยเป็นระยะๆ อุปกรณ์เชิงพาณิชย์สามารถทำงานได้อย่างต่อเนื่องเป็นระยะเวลานาน

สิ่งนี้จะเปลี่ยนข้อกำหนดการออกแบบการระบายความร้อน

OEM Streaming Media Player อาจต้องรองรับการถอดรหัส 4K ที่ยั่งยืน การรับส่งข้อมูลเครือข่าย การเข้าถึงที่เก็บข้อมูลในเครื่อง การเล่นโฆษณา การอนุมาน AI หรือแอปพลิเคชันหลายรายการในขณะที่ทำงานภายในพื้นที่การติดตั้งที่จำกัด

SZTomato สามารถปรับแต่งโซลูชันการระบายความร้อนเฉพาะทางตามปริมาณงานเป้าหมาย รวมถึงขนาดของฮีทซิงค์ อินเทอร์เฟซการระบายความร้อน การวางส่วนประกอบ เส้นทางการกระจายความร้อน และการไหลเวียนของอากาศในตู้

เป้าหมายไม่ใช่แค่การลดอุณหภูมิพื้นผิวเท่านั้น เป้าหมายทางวิศวกรรมคือประสิทธิภาพของ SoC ที่เสถียรโดยไม่มีการควบคุมปริมาณความร้อนโดยไม่จำเป็น

โปรแกรมการตรวจสอบเชิงปฏิบัติควรวัด:

• อุณหภูมิ SoC ภายใต้ภาระที่ต่อเนื่อง

• การใช้งาน CPU/GPU

• การใช้ตัวถอดรหัสวิดีโอ

• พฤติกรรมการควบคุมปริมาณความร้อน

• การใช้พลังงาน

• ประสิทธิภาพอุณหภูมิแวดล้อม

• ความเสถียรในการเล่นเป็นเวลานาน

การตรวจสอบความร้อนมีความสำคัญอย่างยิ่งสำหรับการต้อนรับ ป้ายดิจิทัล การขนส่ง จอแสดงผลทางอุตสาหกรรม และการติดตั้งอื่นๆ ที่การเปลี่ยนเครื่องเล่นที่ล้มเหลวต้องใช้ช่างเทคนิค

วิธีสร้างสถาปัตยกรรมเฟิร์มแวร์

การปรับแต่งฮาร์ดแวร์จะสร้างแพลตฟอร์ม การปรับแต่งเฟิร์มแวร์จะกำหนดว่าแพลตฟอร์มนั้นเหมาะสมกับระบบนิเวศของลูกค้าหรือไม่

ภาพลักษณ์ผู้บริโภคมาตรฐานนั้นแทบจะไม่เพียงพอสำหรับการปรับใช้ OEM ขนาดใหญ่

Android, AOSP หรือ Linux?

ควรเลือกระบบปฏิบัติการตามการใช้งาน

Android TV สามารถใช้งานได้เมื่อโปรเจ็กต์ต้องการประสบการณ์ผู้ใช้ที่เน้นทีวีและระบบนิเวศของแอปพลิเคชันที่เข้ากันได้

AOSP ให้การควบคุมพฤติกรรมของระบบได้ดียิ่งขึ้น และมักจะเหมาะสมกว่าสำหรับผลิตภัณฑ์เชิงพาณิชย์ที่มีตราสินค้าซึ่งต้องการตัวเรียกใช้งานที่ปรับแต่งเอง แอปพลิเคชันระบบ การควบคุมเจ้าของอุปกรณ์ หรือสภาพแวดล้อมแอปพลิเคชันที่มีการควบคุม

สามารถใช้ Linux, Debian หรือ Ubuntu ได้ดีกว่าสำหรับแอปพลิเคชันทางอุตสาหกรรม การประมวลผลแบบ Edge ป้ายดิจิทัล มิดเดิลแวร์เฉพาะทาง หรือโปรเจ็กต์ที่การควบคุมระบบระดับ Linux เป็นลำดับความสำคัญ

ปัจจัยสำคัญไม่ใช่ว่าระบบปฏิบัติการใดที่ทันสมัย อยู่ที่ว่าสามารถรักษา BSP, เคอร์เนล, ไดรเวอร์, มิดเดิลแวร์, แอปพลิเคชัน, กลไกการอัพเดต และอินเทอร์เฟซฮาร์ดแวร์ให้เป็นสถาปัตยกรรมผลิตภัณฑ์เดียวได้หรือไม่

การเพิ่มประสิทธิภาพเคอร์เนล Linux / Android

เลเยอร์เคอร์เนลมีความสำคัญเมื่อ SDK/BSP มาตรฐานไม่ได้จัดเตรียมลักษณะการทำงานที่จำเป็น

วิศวกรรมอาจเกี่ยวข้องกับ: ขึ้นอยู่กับโครงการ

• ไดรเวอร์อีเธอร์เน็ตและ Wi-Fi

• การกำหนดค่า USB

• ลักษณะการทำงานของจอแสดงผลและ HDMI

• อินเทอร์เฟซเสียง

• จีพีโอ

• การสื่อสารแบบอนุกรม

• การจัดการพลังงาน

• นโยบายเรื่องความร้อน

• การกำหนดค่าการจัดเก็บข้อมูล

• การเพิ่มประสิทธิภาพการบูต

• สิทธิ์ของระบบ

• การเร่งความเร็วด้วยฮาร์ดแวร์

การเพิ่มประสิทธิภาพเคอร์เนลควรได้รับแรงผลักดันจากข้อกำหนดผลิตภัณฑ์ที่วัดได้

อุปกรณ์ที่บูทเร็วแต่ขาดการเชื่อมต่อเครือข่ายหลังจากการทำงานขยายเวลาไม่ได้รับการปรับให้เหมาะสม เครื่องเล่นที่ถอดรหัสวิดีโอ 4K แต่ร้อนเกินไปหลังจากผ่านไปหลายชั่วโมงก็ไม่ได้รับการปรับให้เหมาะสมเช่นกัน

วัตถุประสงค์คือพฤติกรรมของระบบที่คาดการณ์ได้ภายใต้ปริมาณงานจริง

UI/UX แบบกำหนดเองและเลเยอร์แอปพลิเคชัน

อินเทอร์เฟซผู้ใช้เป็นอีกหนึ่งจุดสร้างความแตกต่างที่สำคัญของ OEM

ตัวเรียกใช้งานที่กำหนดเองสามารถแทนที่หน้าจอหลักของ Android มาตรฐานด้วยสภาพแวดล้อมที่ควบคุมโดยผู้ควบคุมเครื่องซึ่งประกอบด้วย:

• เอกลักษณ์ของแบรนด์

• การนำทางที่กำหนดเอง

• ทางลัดการบริการ

• เนื้อหาที่แนะนำ

• พื้นที่โฆษณา

• บริการด้านการต้อนรับ

• การควบคุมป้ายดิจิตอล

• การเข้าถึงระบบที่ถูกจำกัด

สำหรับแอปพลิเคชันที่ได้รับการจัดการ Device Owner API และกลไกคีออสก์/งานล็อคสามารถจำกัดการเข้าถึงของผู้ใช้ไปยังแอปพลิเคชันที่ได้รับอนุมัติและฟังก์ชันของระบบได้

สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับระบบโทรทัศน์ในโรงแรม การแสดงเชิงพาณิชย์ บริการ IPTV การใช้งานด้านการศึกษา และเครื่องปลายทางแบบหันหน้าเข้าหาสาธารณะ

การรวม SDK/API: การเชื่อมต่อผู้เล่นเข้ากับระบบธุรกิจ

Streaming Media Player จะมีคุณค่ามากขึ้นอย่างมากเมื่อรวมเข้ากับโครงสร้างพื้นฐานที่มีอยู่ของลูกค้า

ซัพพลายเออร์ OEM/ODM อาจจำเป็นต้องเปิดเผยหรือรวม API สำหรับ:

• มิดเดิลแวร์ IPTV

• แพลตฟอร์ม OTT

• แพลตฟอร์ม CMS

• ระบบป้ายดิจิตอล

• การจัดการสมาชิก

• ระบบการโฆษณา

• แพลตฟอร์มการวิเคราะห์

• การจัดเตรียมอุปกรณ์

• การตรวจสอบระยะไกล

• การจัดการเนื้อหา

• การรับรองความถูกต้องระดับองค์กร

นี่คือจุดที่การรวม SDK/API มีความสำคัญมากกว่าสิ่งที่แนบมาจริง

ตัวอย่างเช่น ผู้รวมระบบอาจต้องการผู้เล่นที่ลงทะเบียนตัวเองโดยอัตโนมัติหลังจากการปรับใช้ ดึงข้อมูลการกำหนดค่าจากแพลตฟอร์มคลาวด์ ติดตั้งแอปพลิเคชันที่ได้รับอนุมัติ ดาวน์โหลดเนื้อหา รายงานความสมบูรณ์ของอุปกรณ์ และรับการอัปเดต OTA โดยไม่มีการแทรกแซงทางกายภาพ

ขั้นตอนการทำงานนั้นจะต้องได้รับการพิจารณาในระหว่างสถาปัตยกรรมเฟิร์มแวร์—ไม่ได้ถูกเพิ่มไว้ในภายหลัง

ระบบอัปเดต OTA และการควบคุมผลิตภัณฑ์ระยะยาว

ผู้ซื้อ OEM ควรประเมินวงจรการใช้งานเฟิร์มแวร์ก่อนลงนามในข้อตกลงการผลิต

ผลิตภัณฑ์อาจจัดส่งมาพร้อมกับฮาร์ดแวร์ที่ยอดเยี่ยมและยังคงมีราคาแพงในการใช้งานหากการอัพเดตเฟิร์มแวร์จำเป็นต้องมีการบริการด้วยตนเอง

สถาปัตยกรรม OTA ที่แข็งแกร่งควรจัดการกับ:

• การจัดการเวอร์ชันเฟิร์มแวร์

• การอัปเดตส่วนเพิ่มหรือรูปภาพเต็ม

• กลุ่มอุปกรณ์

• การปรับใช้แบบเป็นขั้น

• นโยบายการอัพเดตอัตโนมัติ

• อัปเดตการยืนยัน

• การกู้คืนล้มเหลวในการอัปเดต

• ย้อนกลับ

• การวินิจฉัยระยะไกล

• การอัปเดตแอปพลิเคชัน

• การจัดการการกำหนดค่า

สำหรับการปรับใช้ขนาดใหญ่ การใช้งาน OTA แบบเป็นขั้นมีความสำคัญอย่างยิ่ง

กระบวนการที่สมเหตุสมผลคือการปล่อยเฟิร์มแวร์ใหม่ให้กับกลุ่มทดสอบที่ได้รับการควบคุมก่อน หลังจากการตรวจสอบความเสถียรแล้ว การอัปเดตสามารถขยายไปยังจำนวนอุปกรณ์ที่ใหญ่ขึ้นได้

ซึ่งจะช่วยลดความเสี่ยงของข้อบกพร่องของเฟิร์มแวร์ตัวเดียวที่ส่งผลต่อฐานที่ติดตั้งทั้งหมด

ความปลอดภัย DRM และ HDCP ต้องได้รับการออกแบบในแพลตฟอร์ม

ฮาร์ดแวร์สตรีมมิ่งทำงานมากขึ้นภายในระบบนิเวศของเนื้อหาที่ได้รับการคุ้มครอง

แพลตฟอร์มอาจต้องการการสนับสนุนสำหรับเฟรมเวิร์ก DRM, การบูตที่ปลอดภัย, การสื่อสารที่เข้ารหัส, การตรวจสอบแอปพลิเคชัน, เอาต์พุต HDMI ที่ป้องกัน HDCP และฟังก์ชันความปลอดภัยที่สนับสนุนฮาร์ดแวร์ ทั้งนี้ขึ้นอยู่กับข้อกำหนดของบริการและผู้ให้บริการเนื้อหา

ควรกำหนดข้อกำหนด DRM และ HDCP ก่อนที่จะสรุปสถาปัตยกรรม SoC และเฟิร์มแวร์

นี่เป็นข้อพิจารณาที่สำคัญของ OEM เนื่องจากความสามารถด้านความปลอดภัยไม่สามารถใช้แทนกันได้ระหว่างชิปเซ็ตเสมอไป การปรับเปลี่ยนซอฟต์แวร์ไม่สามารถชดเชยแพลตฟอร์มฮาร์ดแวร์ที่ขาดคุณลักษณะด้านความปลอดภัยที่จำเป็นได้

สำหรับการปรับใช้เชิงพาณิชย์ ทีมวิศวกรจึงควรกำหนดข้อกำหนดการป้องกันเนื้อหาตั้งแต่เริ่มต้นโครงการ

กระบวนการพัฒนา OEM/ODM ของเครื่องเล่นสื่อสตรีมมิ่งที่ใช้งานได้จริง

โปรแกรม OEM ที่ได้รับการควบคุมควรเป็นไปตามลำดับทางวิศวกรรมที่กำหนดไว้

ระยะที่ 1: คำจำกัดความข้อกำหนด

เอกสาร:

• ตลาดเป้าหมาย

• สถานการณ์การใช้งาน

• ความละเอียดวิดีโอ

• ตัวแปลงสัญญาณที่จำเป็น

• อินเตอร์เฟซการแสดงผล

• อินเทอร์เฟซเครือข่าย

• ระบบปฏิบัติการ

• แรม/พื้นที่เก็บข้อมูล

• ข้อกำหนดการสมัคร

• ข้อกำหนด DRM

• ข้อกำหนดของโอตะ

• สภาพแวดล้อม

• ปริมาณการผลิตเป้าหมาย

เอกสารนี้จะกลายเป็นพื้นฐานสำหรับการเลือกแพลตฟอร์ม

ขั้นตอนที่ 2: การเลือกแพลตฟอร์มและ PCBA

เลือก SoC และสถาปัตยกรรมอ้างอิงตามปริมาณงาน

จากนั้นจึงพิจารณาว่าส่วนประกอบใดที่สามารถคงไว้ซึ่งมาตรฐานได้ และส่วนประกอบใดต้องมีการปรับเปลี่ยน

ซึ่งจะช่วยลด NRE ที่ไม่จำเป็นและหลีกเลี่ยงการออกแบบส่วนที่มีเสถียรภาพของแพลตฟอร์มใหม่โดยไม่มีเหตุผลทางธุรกิจ

ระยะที่ 3: การพัฒนาเฟิร์มแวร์และ SDK

สร้าง BSP, การกำหนดค่าเคอร์เนล, ไดรเวอร์, บริการระบบ, แอปพลิเคชัน, ตัวเรียกใช้งาน, UI/UX, API และเฟรมเวิร์ก OTA ที่จำเป็น

ควรทดสอบเฟิร์มแวร์กับฮาร์ดแวร์ที่ใช้งานจริง ไม่ใช่แค่ทดสอบกับบอร์ดพัฒนาเท่านั้น

ระยะที่ 4: EVT, DVT และการตรวจสอบการผลิต

การทดสอบการตรวจสอบทางวิศวกรรมควรระบุปัญหาฮาร์ดแวร์และเฟิร์มแวร์ตั้งแต่เนิ่นๆ

การทดสอบการตรวจสอบการออกแบบควรตรวจสอบผลิตภัณฑ์ทั้งหมดภายใต้สภาวะการทำงานที่คาดหวัง

การทดสอบควรรวมถึง:

• การเล่นวิดีโอเป็นเวลานาน

• การหยุดชะงักของเครือข่ายและการกู้คืน

• ลักษณะการทำงานของฮอตปลั๊ก HDMI

• ความเสถียรของไวไฟ

• ปริมาณงานอีเทอร์เน็ต

• การกู้คืนการหยุดชะงักของ OTA

• การทดสอบวงจรกำลัง

• ความเครียดจากความร้อน

• ความน่าเชื่อถือในการจัดเก็บ

• ความเสถียรของแอปพลิเคชัน

• ฟังก์ชั่นการจัดการระยะไกล

หลังจากที่พื้นที่เหล่านี้ได้รับการตรวจสอบแล้วเท่านั้นจึงควรดำเนินโครงการไปสู่การผลิตจำนวนมาก

เหตุใดความสามารถทางวิศวกรรมของ OEM/ODM จึงมีความสำคัญมากกว่าข้อกำหนดเฉพาะของกล่อง

เครื่องเล่นสื่อสตรีมมิ่งสองตัวสามารถใช้ SoC เดียวกันและให้ผลลัพธ์เชิงพาณิชย์ที่แตกต่างกันโดยสิ้นเชิง

ความแตกต่างมักมาจากการนำไปปฏิบัติ

เค้าโครง PCB, การเลือกหน่วยความจำ, การออกแบบการระบายความร้อน, การควบคุมพลังงาน, คุณภาพ BSP, การกำหนดค่าเคอร์เนล, ความเสถียรของไดรเวอร์, สถาปัตยกรรมตัวเรียกใช้งาน, การรวมแอปพลิเคชัน, การออกแบบ OTA และคุณภาพการผลิต ล้วนส่งผลต่อผลิตภัณฑ์ขั้นสุดท้าย

นี่คือเหตุผลที่ทีมจัดซื้อควรประเมินซัพพลายเออร์ OEM/ODM ในระดับวิศวกรรม

แนวทางของ SZTomato ขึ้นอยู่กับการควบคุมเลเยอร์เหล่านี้ แทนที่จะมองว่า OEM เป็นบริการปรับแต่งเครื่องสำอาง ความสามารถครอบคลุมถึงการปรับเปลี่ยนฮาร์ดแวร์ PCBA, การพัฒนาแพลตฟอร์ม SoC, เฟิร์มแวร์แบบกำหนดเอง, การเพิ่มประสิทธิภาพ Android/Linux, การรวม SDK/API, UI/UX แบบกำหนดเอง, ระบบ OTA และโซลูชันระบายความร้อนเฉพาะทาง

โมเดลนี้เหมาะกับโปรเจ็กต์ที่ลูกค้าต้องการ Streaming Media Player ที่แตกต่าง แทนที่จะเป็นกล่องขายปลีกทั่วไป

สถาปัตยกรรมเดียวกันนี้สามารถปรับใช้กับผู้ให้บริการ IPTV, ผู้ให้บริการ OTT, โครงการโทรคมนาคม, กลุ่มการบริการ, บริษัทป้ายดิจิทัล, ผู้วางระบบ และแอปพลิเคชันทางอุตสาหกรรม

รายการตรวจสอบ OEM/ODM สำหรับผู้จัดการฝ่ายจัดซื้อแบบ B2B

ก่อนที่จะเลือกผู้ผลิต Streaming Media Player ให้ถามคำถามเหล่านี้:

ฮาร์ดแวร์

• PCBA สามารถปรับเปลี่ยนได้หรือไม่?

• การกำหนดค่า RAM และที่เก็บข้อมูลสามารถปรับแต่งได้หรือไม่

• Ethernet, Wi-Fi, USB, RS-232, GPIO หรืออินเทอร์เฟซอื่น ๆ สามารถเปลี่ยนได้หรือไม่

• ผู้ผลิตควบคุมการออกแบบการระบายความร้อนหรือไม่?

เฟิร์มแวร์

• สามารถปรับแต่งเฟิร์มแวร์ Android/AOSP/Linux ได้หรือไม่

• เคอร์เนล Linux/Android สามารถแก้ไขได้หรือไม่

• กระบวนการบู๊ตและบริการของระบบสามารถเปลี่ยนแปลงได้หรือไม่?

• สามารถพัฒนาตัวเรียกใช้งานแบบกำหนดเองและ UI/UX ได้หรือไม่

บูรณาการ

• ซัพพลายเออร์สามารถผสานรวม SDK และ API ได้หรือไม่

• สามารถใช้ฟังก์ชัน Device Owner และ Kiosk ได้หรือไม่

• มิดเดิลแวร์และแพลตฟอร์ม 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 สำหรับธุรกิจที่ต้องการแพลตฟอร์มที่กำหนดค่าได้ ซึ่งได้รับการออกแบบทางวิศวกรรมตามข้อกำหนดด้านบริการ มิดเดิลแวร์ และการใช้งานของตนเอง