بالنسبة إلى الاختيار المحدد بين RX 6400 وIntel Arc A310 في نقاش ZimaOS/Jellyfin هذا، فإن Arc A310 أنسب لترميز الوسائط. والسبب ليس أن وحدات معالجة الرسومات من AMD غير مدعومة عمومًا في ZimaOS؛ فقد ظهرت هذه الدعوى في رد مبكر، ثم جرى الاعتراض عليها في النقاش نفسه. أما الفرق الأكثر ثباتًا فيتعلق بقدرات برامج الترميز ودعم Jellyfin الحالي للتسريع على Linux.
ثبّت المستخدم في النهاية بطاقة A310، وأجرى إعداد VA-API/QSV، ثم عرض لاحقًا بيانات فعلية intel_gpu_top نشاط محرك الفيديو أثناء إجراء FFmpeg للترميز. وهذا دليل أقوى بكثير من مجرد ظهور أداة GPU في لوحة معلومات ZimaOS.
لماذا كان Arc A310 خيارًا أفضل من RX 6400
يذكر دليل تسريع وحدات معالجة الرسومات من Intel في Jellyfin الحالي أن QSV هو الخيار المفضل في وحدات معالجة الرسومات الرئيسية من Intel، وأنه يدعم صراحةً عتاد Arc من السلسلة A على Linux. كما تدعم وحدات Arc من السلسلة A ترميز AV1، وهو أمر مهم لبطاقة مخصصة لترميز الوسائط.
يعرض دليل توافق وحدات معالجة الرسومات في ZimaOS الحالي وحدات Intel A310 وA380 وA580 وA750 وA770 في جدول توافق سلسلة Intel A.
قد يجعل التشغيل المباشر وحدة معالجة رسومات عاملة تبدو خاملة
كان من أهم التصحيحات المفيدة في النقاش أن التشغيل المحلي قد يستخدم التشغيل المباشر للملف المصدر. وفي هذه الحالة، لا يكون لدى Jellyfin سبب كبير لاستخدام وحدة معالجة الرسومات بكثافة. وللتحقق من الترميز العتادي، شغّل عمدًا مسارًا بمعدل بت أقل أو بترميز غير متوافق، أو فعّل حرق الترجمة، أو استخدم أي حالة أخرى تفرض التحويل.
كل من QSV وVA-API مهمان على Linux
انتقل المجتمع من VA-API إلى Intel Quick Sync. وهذا يتوافق مع إرشادات Jellyfin الحالية: يُفضَّل QSV عمومًا على أجهزة Intel الحديثة الشائعة المدعومة، بينما يظل VA-API متاحًا ومهمًا للمسارات الأقدم أو التي تركز على التوافق.
لا تحدد كل مربعات ترميز برامج الترميز بشكل عشوائي. فعّل فقط التنسيقات التي تكشفها فعليًا حزمة العتاد وبرنامج التشغيل.
أعد تشغيل Jellyfin بعد تغيير إعدادات التسريع
لا تُطبَّق عدة إعدادات في Jellyfin إلا بعد إعادة تشغيل عملية الخادم. كما فعّل المستخدم تسريع العتاد لإنشاء صور trickplay، ما قد يقلل حمل وحدة المعالجة المركزية أثناء إنشاء صور المعاينة، لكنه يضيف عبئًا آخر على وحدة معالجة الرسومات أثناء معالجة المكتبة.
حقل جهاز QSV الفارغ لا يثبت وجود عطل
كان المستخدم قلقًا لأن Jellyfin لم يعرض اسم جهاز QSV بالطريقة نفسها التي عرضه بها نظام آخر. واقترحت ردود المجتمع ترك الحقل فارغًا واختبار سلوك تحويل الترميز الفعلي بدلًا من استنتاج المشكلة من تسمية الواجهة وحدها.
التحقق من وحدة معالجة الرسومات على المضيف وأثناء تحويل ترميز فعلي
كان أقوى دليل في النقاش هو النشاط أثناء التشغيل: intel_gpu_top أظهر أن محرّك الفيديو مشغول أثناء تشغيل عملية FFmpeg. وهذا يثبت أكثر من مجرد قائمة أجهزة ثابتة، لأنه يوضح أن محرّك الوسائط كان يعمل لحظة إجراء تحويل الترميز.
يوضح دليل تسريع الأجهزة الحد نفسه بين التشغيل المباشر وتحويل الترميز، بينما يساعد دليل أجهزة Jellyfin في تحديد ما إذا كانت هناك حاجة إلى GPU مخصص أصلًا.
مصدر التطبيق والإصدار مهمان أيضًا
تطرّق النقاش أيضًا إلى فئات مصادر متجر التطبيقات وإصدارات Jellyfin الأحدث. لا يضمن عمل GPU المضيف أن تكشف كل صورة حاوية عن /dev/dri أو تتضمن مكتبات FFmpeg/الوسائط نفسها. عند فشل التسريع بعد تحديث أحد التطبيقات، قارِن تعريف الحاوية وتعيينات الأجهزة قبل إلقاء اللوم على البطاقة.
تشغيل المتصفح طبقة توافق منفصلة
النقاش حول صوت DTS وDolby منفصل عن اكتشاف GPU. قد يفرض المتصفح تحويل الترميز أو يفشل في تمرير تنسيق صوتي يمكن لعميل Jellyfin مخصص التعامل معه مباشرةً. استخدم نوع العميل ومعلومات التشغيل عند تحديد ما إذا كانت «مشكلة GPU» هي في الواقع مشكلة توافق مع عميل الوسائط.
ما حققه المستخدم في النهاية
بحلول نهاية النقاش، أفاد المستخدم بأن تحويل الترميز كان يعمل جيدًا عمومًا. ومع ذلك، كشفت رحلة الإعداد عن بعض النقاط غير المصقولة—مثل تسميات واجهة المستخدم المفقودة، واختلاف سلوك الوسائط الأقدم، وبعض عدم اليقين بشأن الإعدادات—لكن بطاقة A310 كانت تنفّذ عملًا حقيقيًا على الفيديو.
الخلاصة
تُعد Intel Arc A310 خيارًا منطقيًا لبطاقة تحويل ترميز Jellyfin المدمجة على Linux/ZimaOS الحالي، لأن Jellyfin يدعم QSV/VA-API على Arc، كما تُدرج ZimaOS حاليًا بطاقة A310 في جدول توافق Intel لديها. تحقّق من نجاحها عبر فرض تحويل ترميز فعلي ومراقبة نشاط محرك GPU، لا عبر أداة لوحة معلومات ZimaOS وحدها.
