فك التشفير بالعتاد مقابل فك التشفير بالبرمجيات: لماذا تدور مروحة جهازك

طريقتان لتحويل تدفق فيديو مضغوط إلى صور. تُنتجان المخرَج نفسه، ولا يكاد شيء آخر فيهما يتشابه.

ما كل واحدة منهما#

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

فك التشفير بالبرمجيات يشغّل مفكّك التشفير شيفرةً عادية على معالجك المركزي، عبر عدة أنوية. وهو يعمل مع أي ترميز تدعمه البرمجية، أي ما يقارب كلها، ويكلّف وقتًا حقيقيًا من المعالج.

الفرق الأهم: دعم العتاد ثنائي لكل ترميز. فوحدة الرسوميات لديك إما تملك مفكّكًا لـ AV1 أو لا تملكه. لا تسريع جزئي، ولا وضع متدنٍّ، ولا «عتاد في الغالب». فإن غابت الكتلة، وقع العمل كله على البرمجيات.

الإعداد، وما يُصدره فعلًا#

ثلاث حالات، تقابل ثلاثة اختيارات لمفكّك التشفير تُسلَّم إلى المشغّل مع كل قطعة وسائط:

Auto   avcodec-hw=d3d11va   ask for the Direct3D 11 video decoder
On     avcodec-hw=any       take any hardware decoder available
Off    avcodec-hw=none      software only

Auto هو الصواب لمعظم الناس تقريبًا. وOff أداة تصحيح: إن أظهرت قناة تشوّهًا أو فشلت في الانفتاح، فإن إجبار فك التشفير البرمجي يخبرك من محاولة واحدة هل أنت أمام مشكلة في برنامج التشغيل أم مشكلة في التدفق.

تفصيل بنيوي واحد، لأنه سبّب خللًا حقيقيًا. هذا خيار لكل وسيط، يُطبَّق كل مرة تُفتح فيها قطعة وسائط، لا مفتاحًا على مستوى المثيل يُضبط مرة واحدة عند البدء. وذلك هو التصميم الصحيح. لكنه يعني أيضًا أن على كل مسار تشغيل أن يتذكر تطبيقه.

الخلل الذي اختبأ في تلك الفجوة بالذات#

حتى 2026-08-23، كان التلفزيون المباشر يحترم إعداد التسريع بينما كان مسار الطلب يثبّته على الإيقاف. فكان كل فيلم وكل حلقة يُفكّ تشفيرهما بالبرمجيات، بصرف النظر عما يقوله الإعداد، على كل جهاز.

أخطأنا في هذا، ولم يكن شيء منه ظاهرًا من الواجهة. كان الإعداد موجودًا، ومحفوظًا، ويقول Auto، والأفلام تُفكّ بالبرمجيات على أي حال. وظهر الأمر على هيئة «الأفلام تجعل المروحة تدور والتلفزيون المباشر لا»، وهو عَرَض يسهل إلقاء تبعته على حجم الملف أو معدل البت.

بعد الإصلاح، شُغّل عنوان 4K ذاته ومحركات فك تشفير الفيديو في وحدة الرسوميات عند نحو 11 بالمئة. الملف نفسه، والجهاز نفسه، والإعداد نفسه.

سبب تدوين هذا بدل إصلاحه في صمت: إنه أوضح مثال على لماذا تتحقق من أن فك التشفير بالعتاد يعمل فعلًا بدل أن تثق بإعداد. افتح لوحة معلومات التدفق، وراقب محرك فك تشفير الفيديو في وحدة الرسوميات لديك في مدير المهام أثناء تشغيل شيء ما. تدفق 4K مع محرك فك تشفير الفيديو قرب الصفر وأنوية المعالج محمَّلة هو فك تشفير برمجي، أيًّا كان ما يقوله الإعداد.

الخيوط، وكلفة لم تكن لتتوقعها#

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

حين تُرك ليختار بنفسه، اختار مفكّك التشفير 6 خيوط على جهاز القياس. وأنتج ذلك مجمّع إخراج Direct3D 11 من 40 سطحًا بدقة 4K، أي نحو 500 MB من الالتزام المرئي لوحدة الرسوميات. وأمام ميزانية Xbox البالغة نحو 1 GB، فذلك نصف الذاكرة المسموح بها للتطبيق كله، مصروفًا على مخازن مفكّك التشفير. لم أتوقع أن يكون عدد الخيوط قرارًا يتعلق بالذاكرة.

لذلك يحدّه الكونسول عند 3.

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

الرافعة الأخرى، وهي ليست إعدادًا لمفكّك التشفير#

إن كانت كلفة فك التشفير هي مشكلتك، فالدقة رافعة أكبر من اختيار مفكّك التشفير.

تُحدّ بلاطات العرض المتعدد عند 640 في 360 حين تكون صامتة وعند 1280 في 720 حين تحمل الصوت، وذلك الحد هو ما يجعل شبكة من 9 بلاطات ممكنة أصلًا. وهو أقل ما يكون تنازلًا عن الجودة وأكثر ما يكون إقرارًا بأن بلاطة عرضها 4 بوصات لا تستفيد من 1080p.

والمنطق نفسه يسري على قناة يعاني جهازك معها. فإن كان مزوّدك يقدّم القناة نفسها بجودة أدنى، فذلك غالبًا جواب أفضل من أي إعداد، لأنه يقلّل العمل بدل أن يعيد توزيعه.

كيف تتحقق منه فعلًا، في غضون 2 دقيقتين#

الإعداد ليس دليلًا. هذا هو الدليل.

افتح مدير المهام، واذهب إلى الأداء، واختر وحدة الرسوميات لديك، وغيّر أحد الرسوم البيانية إلى Video Decode. ثم ابدأ قناة.

Video Decode busy, CPU cores quiet     hardware decoding
Video Decode flat, several cores busy  software decoding

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

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

لوحة معلومات التدفق هي النصف الآخر من الفحص، لأنها تخبرك أي ترميز تطلب من الجهاز فكّه. حقلا البروتوكول والحاوية فيها مستخرَجان من العنوان لا من مفكّك الحزم؛ وحقل ترميز الفيديو هو الذي يجيب عن هذا السؤال.

كلفة الذاكرة، وهي الجزء المفاجئ#

يُناقَش فك التشفير عادةً بوصفه مقايضة بين المعالج المركزي ووحدة الرسوميات. لكنه على جهاز محدود الذاكرة قرار يتعلق بالذاكرة بقدر ما يتعلق بالمعالجة، والأرقام ليست بديهية.

تخصّص خيوط الأطر مخازن صور. وخيوط أكثر تعني مخازن أكثر قيد المعالجة، وكل مخزن بدقة 4K كبير. تلك هي القصة كلها وراء مجمّع الـ 500 MB أعلاه، وهي سبب كون الحد 3 وليس رقمًا اختير لأسباب تتعلق بالمعالج. وهي أيضًا سبب كون الحد بلا كلفة حيث يعمل فك التشفير بالعتاد: فمسار العتاد لا يخصّص تلك المخازن أصلًا.

والسياق الأوسع يزيده حدّة. فقياسنا نحن لجلسة تصفح مدتها 12 دقيقة على سطح المكتب انتهى عند 918 MB من مجموعة العمل وبلغ ذروته عند 1,080 MB، أمام ميزانية داخلية قدرها 400 MB، مع كومة مُدارة ثابتة عند نحو 62 MB عبر الدورات ذاتها. النمو أصلي (native)، ومخازن مفكّك التشفير أصلية. وعلى كونسول متاح فيه نحو 1 GB، مسار فك تشفير برمجي يريد 500 MB من المجمّعات ليس مشكلة أداء. إنه إنهاء للتطبيق.

لماذا «ارجع إلى البديل فحسب» ليس تصميمًا#

اقتراح يبدو معقولًا: جرّب العتاد، وإن فشل، فانتقل إلى البرمجيات آليًا وبصمت.

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

لذلك تُحسب مجموعة المفاتيح المُصدَرة مسبقًا، لكل رأس، من قائمة سماح، مع اختبارات تؤكد أن كل تركيبة من الرأس والدور والإعداد وعمق السطح لا تُصدر إلا مفاتيح مسموحًا بها. والبديل، أي اكتشاف الدعم بالتجربة، يعني أن المحاولة الفاشلة تكلّف مثيلًا كاملًا وتُنتج خطأ لا يشير إلى شيء.

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

هناك سُلّم بدائل حقيقي، وهو يُظهر كيف يبدو السُلّم حسن السلوك. يجرّب سطح الفيديو 3 تكوينات بالترتيب:

1  R10G10B10A2 + Ignore        preferred, 10-bit
2  R10G10B10A2 + Unspecified   10-bit, different alpha handling
3  B8G8R8A8 + Unspecified      8-bit, identical to the previous behaviour

ما يجعل ذلك السُلّم آمنًا هو درجته الأخيرة: فهي مطابقة بايتًا ببايت للتكوين الذي كان يُشحن قبل أن يوجد أي من هذا، فالجهاز الذي لا يستطيع تركيب 10 بت يتصرف تمامًا كما كان دائمًا بدل أن يدخل حالة غير مختبَرة. والفشل الكلي يُسجَّل ويترك السطح غير محمَّل بدل أن يرمي استثناءً من رد نداء التخطيط، وهو ما كان سيُسقط التطبيق.

البديل لا يكون بديلًا إلا إذا كانت درجته الأدنى معلومة الصلاح.

ما الذي تفحصه، بالترتيب#

هل فك التشفير بالعتاد يعمل فعلًا؟ انظر إلى محرك فك تشفير الفيديو في وحدة الرسوميات، لا إلى الإعداد.

إن لم يكن، فهل يوجد مفكّك تشفير بالعتاد لهذا الترميز على هذا الجهاز؟ H.264 وHEVC وAV1 يغطي أين تقع الحدود، وAV1 هو حيث يقع معظمها.

إن وُجد، فهل برامج تشغيل وحدة الرسوميات لديك محدَّثة؟ نصيحة مملّة، وأحيانًا هي الجواب كله، لأن دعم مفكّكات التشفير يُشحن في برامج التشغيل.

وإن كان هذا الجهاز لن يفكّ تشفير هذا الترميز بالعتاد أبدًا، فالخيارات هي جودة أدنى، أو ترميز مختلف من المزوّد، أو عتاد مختلف. لا إعداد يعوّض دارة غير موجودة.