يثبت نجاح H.264 أن مسار وحدة معالجة الرسومات يعمل مع H.264، لكنه لا يثبت أن العتاد نفسه يدعم فك ترميز AV1 أو ترميزه أو ملفه التعريفي أو عمق البت.
التحويل بالعتاد عبارة عن سلسلة من العمليات الخاصة بكل برنامج ترميز: فك ترميز المصدر، وتطبيق التحجيم أو تخطيط النغمة، ثم ترميز تنسيق الإخراج الذي اختاره العميل. تعمل وحدات معالجة الرسومات الأقدم ومتوسطة الجيل غالبًا على تسريع H.264، مع دعم فك ترميز AV1 برمجيًا فقط، أو دعم فك ترميز AV1 بالعتاد دون ترميز AV1، أو عدم دعم أي منهما. ابدأ بتحديد مرحلة AV1 التي تفشل قبل تغيير إعدادات التسريع العامة.
حدّد ما إذا كان فك ترميز AV1 أو ترميزه هو الذي يفشل
افحص أمر FFmpeg النشط وسبب التحويل. سجّل برنامج ترميز الإدخال، وفك الترميز بالعتاد، ومسار المرشح، وبرنامج ترميز الإخراج، ومشفّر العتاد، وأول سطر خطأ.
قد يفك الخادم ترميز AV1 ويرمّز H.264، أو يفك ترميز H.264 ويحاول ترميز AV1. هذه قدرات مختلفة. تتضمن إحدى مناقشات Jellyfin حول العتاد نظامًا كانت فيه مسارات AV1 QSV وVA-API غير مدعومة على وحدة معالجة الرسومات المثبتة، بينما ظلت مسارات العتاد الأخرى قابلة للاستخدام.
شغّل اختبارًا واحدًا من إدخال AV1 إلى إخراج H.264، واختبارًا آخر من إدخال H.264 إلى إخراج AV1، ولكن فقط عندما يتيح خادم الوسائط الخيارين. إذا نجح الاختبار الأول وفشل الثاني، فهذا يعني أن فك ترميز AV1 موجود، لكن ترميز AV1 غير مدعوم.
تحقق من قدرة العتاد حسب اتجاه برنامج الترميز وملفه التعريفي
ابحث عن جيل وحدة معالجة الرسومات الفعلي ومعرّف الجهاز، ثم قارن دعم فك الترميز بالترميز كلٌّ على حدة. أدرج ملف AV1 Main التعريفي، و8 بت مقابل 10 بت، وتنسيق الألوان، والدقة، والحد الأقصى للمستوى.
قد يكون دعم برنامج الترميز جزئيًا حتى في الأجهزة الأحدث. يوضح تقرير عن برنامج تشغيل الوسائط من Intel فشل فك ترميز AV1 بالعتاد على Tiger Lake مع نجاح فك الترميز برمجيًا، مما يبيّن أن مسار AV1 المتاح قد يظل يفشل مع تركيبة معينة من النواة وبرنامج التشغيل.
لا تستنتج قدرة AV1 من استخدام H.264 أو عائلة طراز وحدة معالجة الرسومات أو مربع اختيار في التطبيق. أكّد ملف المصدر التعريفي الفعلي ونقطة الإدخال المطلوبة للإخراج، وقارنهما بما يبلّغ عنه المكدس المثبت.
اقرأ ملفات تعريف فك الترميز والترميز التي يوفّرها المضيف
شغّل أداة قدرات المنصة على جهاز العرض أو CUDA المقصود. بالنسبة إلى VA-API، التقط مخرجات الملف التعريفي ونقطة الإدخال؛ وبالنسبة إلى NVIDIA، التقط برنامج التشغيل المثبت وقائمة مفككات الترميز والمشفّرات المتاحة في FFmpeg.
قد يظهر AV1 لفك الترميز دون الترميز، أو قد يتطلب وضع الترميز منخفض الطاقة برنامجًا ثابتًا لا يحتاج إليه H.264. يشير مستودع برنامج تشغيل الوسائط من Intel إلى أن التحكم في معدل البت منخفض الطاقة لبرامج AVC وHEVC وVP9 وAV1 قد يعتمد على توافر البرنامج الثابت HuC.
إذا لم يوفّر المضيف نقطة إدخال AV1 المطلوبة، فتوقف عند طبقة المضيف. لا يمكن لتغيير أذونات الحاوية أو إعدادات خادم الوسائط إنشاء كتلة ترميز لا توفرها النواة وبرنامج تشغيل مساحة المستخدم.
قارن إصدارات النواة والبرنامج الثابت وبرنامج تشغيل مساحة المستخدم
سجّل إصدار النواة، وحزمة البرنامج الثابت، وبرنامج تشغيل وحدة معالجة الرسومات في مساحة المستخدم، ومكدس libva أو CUDA، وبيئة تشغيل الحاوية، وإصدار FFmpeg. قد يظل H.264 مستقرًا بعد تحديث ما، بينما يتراجع مسار AV1 الأحدث.
أبلغت عمليات النشر الأولى لوحدات Intel Arc عن حالات فشل في فك الترميز والترميز عبر VA-API أثرت في AV1 إلى جانب برامج ترميز أخرى، إلى أن نضج مكدس النواة وبرنامج تشغيل الوسائط المحيط. توضح هذه الحالة سبب أهمية توافق مكدس برامج التشغيل بدرجة أكبر لمسار برنامج ترميز أحدث.
قارن الإصدارات الحالية بآخر إعداد معروف بنجاحه وبتركيبة الحزم المدعومة في التوزيعة. تجنب مزج برنامج تشغيل وسائط جديد في مساحة المستخدم مع نواة قديمة غير متوافقة، أو استبدال مكونات FFmpeg المعبأة فرديًا.
اختبر الجهاز نفسه وإصدار FFmpeg نفسه داخل الحاوية
ادخل إلى حاوية خادم الوسائط وتحقق من عقدة العرض أو جهاز NVIDIA، والمجموعات الرقمية، ومكتبات برنامج التشغيل، وقائمة برامج ترميز FFmpeg المضمّنة. لا تثبت قدرة المضيف أن الحاوية تستخدم المكدس نفسه.
مرّر عينة AV1 قصيرة ومعروفة بسلامتها عبر فك الترميز بالعتاد وإخراج H.264 بسيط من دون HDR أو ترجمة أو تحجيم. ثم كرر الاختبار باستخدام ملف FFmpeg الثنائي الخاص بالتطبيق وتحديد الجهاز الفعلي فيه.
يوفّر دليل ZimaSpace حول التحقق من عمل التحويل بالعتاد اختبارًا مرتبطًا لإثبات أن الحاوية تستخدم الجهاز المتوقع بدلًا من الرجوع بصمت إلى البرمجيات.
افصل معالجة فيديو AV1 عن مشكلات حاوية التسليم
قد يُفك ترميز مصدر AV1 بشكل صحيح، لكنه يفشل عندما يطلب العميل تحويل الصوت أو نوعًا مختلفًا من مقاطع HLS أو معالجة HDR أو حاوية تسليم لا تحمل التركيبة المختارة.
وجدت إحدى مشكلات Jellyfin Web أن تشغيل AV1 مع تحويل الصوت يفشل عند استخدام أحد خيارات حاوية HLS، لكنه يعمل عند تفعيل fMP4-HLS، مما يوضح أن حاوية التسليم قد تكون طبقة الفشل.
أعد الاختبار باستخدام ملف AV1 بسيط بنطاق SDR وصوت متوافق ومن دون ترجمة وإخراج H.264. أضف تحويل الصوت، وتخطيط نغمة HDR، والترجمة، وملف تعريف العميل المعتاد، متغيرًا واحدًا في كل مرة.
استخدم الرجوع إلى البرمجيات أو إخراجًا متوافقًا بعد التصنيف فقط
إذا كانت وحدة معالجة الرسومات تدعم فك ترميز AV1 ولا تدعم ترميزه، فأبقِ فك الترميز بالعتاد، ورمّز إخراج العميل بصيغة H.264 أو HEVC عند دعمهما. وإذا لم يتوفر فك ترميز AV1، فقد يعمل فك الترميز البرمجي مع الدقات المنخفضة، لكنه قد يكون بطيئًا جدًا مع فيديو 4K عالي معدل البت.
يؤثر دعم العميل أيضًا في مدى فائدة إخراج AV1. فقد تتبع Jellyfin Web ملفات تعريف للمتصفحات تواصل اختيار H.264 لأن دعم العميل لـ AV1 لا يزال يعتمد على ملف التعريف.
يكتمل الإصلاح عندما يستخدم ملف AV1 الذي اختبرته مفكك الترميز بالعتاد المقصود أو رجوعًا برمجيًا مقاسًا، ويتوافق برنامج ترميز الإخراج مع العميل، وتظل سرعة التحويل أعلى من الزمن الفعلي، وتستمر جلسات H.264 في العمل بعد التغيير الخاص بـ AV1.
الدعم والنصائح
المزيد للقراءة

لماذا تؤدي استعادة وحدة تخزين Docker إلى إعادة إنشاء محتويات الملفات مع فقدان السمات الموسّعة؟
تشخيص لاستعادة وحدة تخزين يغطي جرد السمات الموسَّعة (xattr)، وخيارات tar وRsync، ومساحات الأسماء، ودعم الوجهة، والامتيازات، والتسميات، والبيانات الوصفية للتطبيق، والاختبارات.

لماذا يحتفظ الحاوي قيد التشغيل بحد الذاكرة القديم بعد تغيير ملف Compose؟
تشخيص لحدود الذاكرة يغطي مجموعات cgroups النشطة، وإعادة التشغيل مقابل إعادة الإنشاء، وحقول Compose، والحدود الصارمة والمرنة، والنطاقات الأصلية، وذاكرة التبديل، وأكوام الذاكرة في...

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

