إعداد تحويل Jellyfin العتادي باستخدام NVIDIA وDocker

ما الذي ستبنيه

يتكوّن إعداد تحويل الفيديو العتادي في Jellyfin باستخدام وحدة معالجة رسومات NVIDIA من 4 خطوات بترتيب ثابت، ولا تُنفَّذ الخطوة الأخيرة إلا داخل Jellyfin. لا يمكن للحاوية رؤية وحدة معالجة رسومات لم يحمّل برنامج تشغيل المضيف لها. ولا يمكن لـJellyfin استخدام وحدة معالجة رسومات لا تراها الحاوية. نفّذ الخطوات بهذا الترتيب، وستعرف بوضوح أين تبحث عند حدوث أي عطل.

1. ثبّت برنامج تشغيل NVIDIA على المضيف، ثم تحقّق منه باستخدام nvidia-smi.
2. ثبّت NVIDIA Container Toolkit حتى يتمكّن Docker من إتاحة وحدة معالجة رسومات للحاوية.
3. احجز وحدة معالجة الرسومات لخدمة Jellyfin في docker-compose.yml، ثم تحقّق من أن الحاوية تراها.
4. فعّل NVENC وNVDEC في إعدادات التشغيل الخاصة بـJellyfin، ثم تحقّق من أن تشغيل فيديو فعلياً يستخدمهما.

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

التشغيل المباشر يتفوق على كل عمليات التحويل، لذا تحقّق منه أولاً

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

افتح Dashboard، ثم Playback، وراقب جلسة نشطة أثناء تشغيل محتوى. ترسل الجلسة التي تحمل الحالة Direct playing الملف دون تعديل تقريباً، ولا تستهلك إلا قدراً ضئيلاً من CPU. أما الجلسة التي تحمل الحالة Transcoding فتُظهر السبب الذي اختاره Jellyfin. أزل هذا السبب، ولن تحتاج وحدة GPU إلى العمل إطلاقاً.

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

الترجمات المعتمدة على الصور هي الاستثناء الذي لا يصلحه أي إعداد للعميل. ترجمات PGS من نسخة Blu-ray وترجمات VOBSUB من نسخة DVD عبارة عن صور، لذلك يجب رسمها فوق الفيديو نفسه، ما يعني إعادة ترميز كاملة لتدفق الفيديو. أما الترجمات النصية بتنسيق SRT فتُرسل إلى العميل كمسار منفصل ولا تستهلك موارد تُذكر. ويستحق تحويل مسارات الترجمة إلى نص، حيثما أمكن، موارد أكثر من شراء GPU. يتناول الدليل الخاص بتشغيل خادم Jellyfin للوسائط على VPS بقية إعدادات جانب الخادم.

لا تتضمن معظم خطط VPS أي GPU على الإطلاق

لا تتضمن خطط VPS القياسية أي GPU. نفّذ هذا الأمر على الخادم قبل التخطيط لأي شيء آخر.

lspci -nn | grep -Ei "3d|display|vga"

في VPS نموذجي يعمل عبر KVM، يعرض هذا الأمر محول عرض افتراضياً من برنامج hypervisor، أو لا يعرض شيئاً مفيداً. لا يستطيع هذا الجهاز ترميز الفيديو. لا يظهر GPU حقيقي إلا عندما يمرّر المزوّد بطاقة فعلية إلى مثيلك أو يمنحك جزءاً منها، وتكون أسعار هذه الخطط أعلى وفقاً لذلك. يوضّح ما أعباء العمل التي تبرر فعلياً دفع تكلفة VPS مزود بـ GPU من يحتاج إلى ذلك ومن لا يحتاج إليه.

إذا لم يتوفر GPU، فاستهدف التشغيل المباشر واجعل تحويل الترميز بالبرمجيات حالة نادرة. يكون تحويل ترميز برمجي واحد بدقة 1080p وبترميز H.264 حملاً ثقيلاً، لكنه يظل ممكناً على بضع أنوية من CPU. أما تحويل ترميز برمجي بدقة 4K HDR مع tone mapping، فلا يستطيع VPS صغير إتمامه في الوقت الفعلي، ولذلك يتقطع البث بينما يظل استخدام CPU عند 100 percent.

ثبّت برنامج تشغيل NVIDIA على المضيف

تذكر وثائق Jellyfin 10.11 أن الحد الأدنى لإصدار برنامج تشغيل NVIDIA على Linux هو 520.56.06. يوفّر Ubuntu أداة مساعدة تختار الحزمة المطابقة لك.

sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu
sudo reboot

يختار --gpgpu إصدار برنامج التشغيل المخصص للخوادم من دون واجهة رسومية. وهذا هو الخيار المناسب لخادم الوسائط لأن الجهاز لا يحتوي على سطح مكتب. يعرض الأمر list الفروع المتاحة لك، ويمكنك تثبيت فرع محدد بالاسم، مثل sudo ubuntu-drivers install --gpgpu nvidia:570-server. استخدم فرعاً عرضه الأمر فعلياً، وليس الفرع المذكور هنا.

لا يثبّت إصدار الخادم الحزمة nvidia-smi دائماً. ثبّت حزمة utils المطابقة للفرع الذي اخترته، مثل sudo apt install nvidia-utils-570-server. ثم تحقّق من برنامج التشغيل.

nvidia-smi

تعرض النتيجة السليمة جدولاً يحتوي في رأسه على إصدار برنامج التشغيل وإصدار CUDA، وتعرض بطاقتك باسمها، وتحتوي قائمة العمليات على لا شيء. يشيع حدوث فشلين هنا. يعني nvidia-smi: command not found أن حزمة utils مفقودة، وليس أن برنامج التشغيل مفقود. يعني NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver أن وحدة kernel غير محمّلة. في التثبيت الجديد، يعني ذلك غالباً أنك لم تُعد تشغيل الخادم بعد، أو أن Secure Boot يرفض تحميل وحدة غير موقّعة. أكّد وجود الوحدة باستخدام lsmod | grep nvidia.

ثبّت NVIDIA Container Toolkit

يتيح برنامج التشغيل للمضيف استخدام GPU. لكن Docker لن يمرره إلى الحاوية، لأن الحاوية لا تحتوي على عقد الجهاز ولا مكتبات برنامج التشغيل. NVIDIA Container Toolkit هو المكوّن الذي يحقن كليهما عند بدء الحاوية. هذه أوامر التثبيت الرسمية من NVIDIA لنظامي Debian وUbuntu.

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

لا يكفي تثبيت الحزمة، لأن Docker يجب أن يعرف بوجود بيئة التشغيل.

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

يكتب nvidia-ctk runtime configure إدخال بيئة تشغيل nvidia في /etc/docker/daemon.json. إعادة التشغيل هي الخطوة التي يتجاوزها كثيرون، وتجاوزها يسبب الخطأ الأكثر شيوعاً في هذا الإعداد كله. اختبر آلية الربط قبل أن تلمس Jellyfin.

sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

يجب أن يطبع ذلك الجدول نفسه الذي طبعه المضيف. إذا فشل بدلاً من ذلك مع ظهور خطأ يفيد بتعذّر اختيار برنامج تشغيل جهاز ذي إمكانات GPU، فهذا يعني أن Docker daemon لا يعرف بيئة التشغيل nvidia. شغّل أمر الإعداد مرة أخرى، ثم أعد تشغيل daemon.

امنح حاوية Jellyfin إمكانية الوصول إلى GPU في Docker Compose

هذه هي صيغة Compose الحديثة، وهي مطابقة للمثال الذي تنشره Jellyfin.

services:
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    user: 1000:1000
    network_mode: host
    restart: unless-stopped
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=all
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/jellyfin/cache:/cache
      - /srv/media:/media:ro
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

شغّل الحاوية واختبرها مباشرة.

docker compose up -d
docker compose exec jellyfin nvidia-smi

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

تحتاج أربعة أسطر في هذا الملف إلى توضيح. يُعد capabilities: [gpu] مطلوباً من Compose نفسه، وحذفه يجعل Compose يرفض الخدمة بدلاً من تشغيلها دون GPU. ويُعد NVIDIA_DRIVER_CAPABILITIES=all مهماً لأن toolkit لا يركّب مكتبات الفيديو داخل الحاوية إلا عند طلب capability الخاصة بالفيديو، كما توثّق Jellyfin هذا المتغير على أنه مطلوب للصورة الرسمية. بدونه يعمل CUDA، بينما لا يعمل NVDEC، ويسجّل سجل التحويل Cannot load libnvcuvid.so.1. أما network_mode: host فهو المستخدم في المثال الخاص بـJellyfin، لأن الاكتشاف التلقائي للعملاء عبر UDP على المنفذ 7359 لا يعمل عبر شبكة bridge.

أما user: 1000:1000 فهو السطر الأخير، ولا علاقة له بـGPU. فهو يحدد الملفات التي يمكن لـJellyfin قراءتها من mount الخاص بالوسائط، ويؤدي عدم التطابق هنا إلى ظهور مكتبة فارغة بدلاً من خطأ في الصلاحيات. يشرح كيفية ربط PUID وPGID بمستخدم الحاوية والملفات على القرص طريقة ترقيم المستخدمين والمجموعات، وهي الأرقام نفسها التي أعددتها مسبقاً إذا كنت تشغّل مكدس Sonarr وRadarr في Docker Compose بجانب هذه الخدمة.

لماذا لا تزال معظم الأدلة تكتب runtime: nvidia

يظهر الشكل الأقدم في كل دليل تقريباً، وهو ليس خاطئاً. هذا بسبب تاريخه. سجّلت حزمة nvidia-docker2 الأصلية بيئة تشغيل OCI باسم nvidia، لذلك كانت الطريقة الوحيدة لإتاحة وحدة GPU داخل حاوية هي --runtime=nvidia مع NVIDIA_VISIBLE_DEVICES. أضاف Docker 19.03 العلامة --gpus وواجهة مناسبة لطلبات الأجهزة. واستغرق Compose وقتاً أطول ليدعم ذلك. وعندما فعل، وُضعت طلبات الأجهزة ضمن deploy.resources.reservations.devices، وهو مفتاح اعتاد معظم الناس تجاهله لأن deploy كان يعني Docker Swarm سابقاً.

نتيجة ذلك أن كلا الشكلين يعمل اليوم، وأن المثال المنشور لـJellyfin يستخدمهما معاً. لا يسبب الإبقاء على runtime: nvidia أي تكلفة، ويجعل الملف يعمل مع إصدارات Compose الأقدم. إذا أبقيت على runtime: nvidia فقط وحذفت كتلة deploy، فيجب أن تُبقي على NVIDIA_VISIBLE_DEVICES=all، لأن المسار القديم يقرأ متغير البيئة لتحديد الأجهزة التي يجب إتاحتها للحاوية، ولا يملك طلب أجهزة آخر يقرأه بدلاً منه.

فعّل تحويل الترميز باستخدام عتاد NVIDIA داخل Jellyfin

لم يطلب أي إعداد حتى الآن من Jellyfin استخدام البطاقة. انتقل إلى Dashboard، ثم Playback، ثم Transcoding. اضبط Hardware acceleration على Nvidia NVENC. فعّل Enable hardware encoding، وإلا فسيفكّك Jellyfin الترميز على GPU ثم يشفّره على CPU. هذه حالة وسطية مربكة، إذ يظهر نشاط على GPU بينما يظل CPU مستهلكاً للموارد.

فعّل enhanced NVDEC decoder. يبدّل هذا الخيار بين مسار NVDEC الحالي ومسار CUVID الأقدم. اتركه مفعّلاً. تحتاج معالجة Dolby Vision إلى هذا الخيار لاستخدام NVDEC أصلاً.

ضمن Enable hardware decoding for، فعّل برامج الترميز التي تستطيع بطاقتك فك ترميزها فعلياً فقط. هذا هو الإعداد الذي يخطئ فيه المستخدمون غالباً. لا يؤدي تفعيل AV1 على بطاقة لا تحتوي على وحدة فك ترميز AV1 إلى ظهور رسالة خطأ. يطلب Jellyfin فك الترميز عتادياً، ولا يحصل عليه، فينتقل إلى فك الترميز برمجياً. لذلك يرتفع استهلاك CPU ويبقى GPU شبه خامل، وهو ما يبدو تماماً كما لو أن تمرير البطاقة لم يعمل.

ينطبق قيد إضافي على الصفحة بأكملها: لا يعمل تسريع العتاد إلا مع الإصدار jellyfin-ffmpeg المضمّن. إذا وجّهت مسار FFmpeg إلى إصدار FFmpeg الخاص بالنظام، فستحصل على تسريع جزئي أو لن تحصل على أي تسريع.

برامج الترميز التي يستطيع جيل GPU لديك فك ترميزها وترميزها

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

• H.264‏ 8-bit: كل GPU من NVIDIA يدعم NVENC وNVDEC يستطيع فك ترميزه وترميزه.
• HEVC‏ 8-bit: فك الترميز والترميز مدعومان ابتداءً من الجيل الثاني من Maxwell‏ (GM206) وما بعده.
• HEVC‏ 10-bit: فك الترميز مدعوم ابتداءً من الجيل الثاني من Maxwell وما بعده، لكن الترميز مدعوم ابتداءً من Pascal وما بعده فقط.
• AV1: فك الترميز مدعوم ابتداءً من Ampere وما بعده، والترميز مدعوم ابتداءً من Ada Lovelace وما بعده.

الفرق في HEVC‏ 10-bit هو ما يسبب المشكلة عملياً. تستطيع بطاقة من جيل Maxwell فك ترميز ملف 4K HDR على GPU، لكنها لا تستطيع بعد ذلك ترميز خرج 10-bit، لذلك تستخدم Jellyfin ترميز H.264‏ 8-bit بدلاً منه. يظل الملف قابلاً للتشغيل، وهذا هو الخيار الصحيح لمعظم العملاء على أي حال. نادراً ما يكون ترميز AV1 هو الخيار الذي تريده في 2026، بغض النظر عن بطاقتك، لأن دعم فك ترميز AV1 لدى العملاء لا يزال محدوداً، كما أن إجراء transcode ضروري للوصول إلى عميل كان يواجه مشكلة أصلاً.

لماذا تؤدي مطابقة النطاقات إلى إعادة تشبيع GPU بهدوء

تُعد مطابقة النطاقات من HDR (النطاق الديناميكي العالي) إلى SDR (النطاق الديناميكي القياسي) الإعداد الذي يستنزف ميزانية GPU، والسبب معماري. تجري عملية فك الترميز على NVDEC. وتجري عملية الترميز على NVENC. أما مطابقة النطاقات فلا تجري على أيٍّ منهما؛ فهي مرشح CUDA يُنفَّذ على أنوية التظليل، وهي الجزء العام نفسه من GPU الذي ينفّذ مهام الحوسبة. لذلك، يحتاج تدفق 4K HDR الذي يتطلب مطابقة النطاقات إلى وحدة فك الترميز ووحدة الترميز، كما يحمّل أنوية التظليل فوق ذلك.

يوثّق Jellyfin أن مطابقة النطاقات عبر CUDA متاحة على كل GPU من NVIDIA يستطيع فك ترميز HEVC 10-bit. وهذا يعني أن مربع الاختيار يظهر ويعمل على بطاقات لا تستطيع الحفاظ على هذا الحمل عند 4K. وتتمثل الأعراض في بدء التدفق ثم دخوله في التخزين المؤقت دون أن يستقر، بينما تُظهر nvidia-smi أن وحدة الترميز مشغولة بالكاد.

لهذا السبب، تجدر مراقبة حمل أنوية التظليل بشكل منفصل.

nvidia-smi dmon -s u

يطبع ذلك سطراً واحداً كل ثانية، مع أعمدة منفصلة لـsm وenc وdec. وتشير قيمتا enc وdec المنخفضتان إلى جانب قيمة sm المرتفعة إلى أن الكتل ذات الوظائف الثابتة تعمل بحمل منخفض، وأن أنوية التظليل هي عنق الزجاجة. لذلك تكون مطابقة النطاقات أو تغيير الحجم أو حرق الترجمة داخل الفيديو هي العمليات التي تستهلك الموارد. كما يتعامل مسار CUDA مع Dolby Vision profile 5 باستخدام النسخ الصفري، وهذا مهم لأن الإطارات، من دون النسخ الصفري، تنتقل إلى ذاكرة النظام ثم تعود منها بين خطوات المرشح، وتستهلك هذه الرحلة ذهاباً وإياباً عرض النطاق الترددي في كل إطار.

ما الذي يحدّه سقف جلسات NVENC على بطاقات المستهلك فعلياً

[
  {
    "label": "GeForce RTX 5090",
    "nvenc_engines": 3,
    "max_encode_sessions": 12
  },
  {
    "label": "GeForce RTX 4090",
    "nvenc_engines": 2,
    "max_encode_sessions": 12
  },
  {
    "label": "GeForce RTX 4060",
    "nvenc_engines": 1,
    "max_encode_sessions": 12
  }
]

هذه أرقام مصفوفة NVIDIA المنشورة حتى أغسطس 2026، وليست قياسات أُجريت هنا. تُقيَّد بطاقة GeForce بـ 12 جلسة ترميز متزامنة، بصرف النظر عن طرازها. يوجد هذا الحد في برنامج التشغيل وليس في العتاد نفسه، وقد رفعته NVIDIA أكثر من مرة على مر السنين. لذلك راجع المصفوفة الحالية بدلاً من الاعتماد على موضوع قديم في أحد المنتديات. عدد المحركات هو العامل الذي يتغير فعلياً باختلاف البطاقة: تحتوي GeForce RTX 5090 على 3 من محركات NVENC، بينما تحتوي GeForce RTX 4060 على 1. يعني وجود محركات أكثر زيادة معدل الترميز المتوازي، وليس رفع الحد الأقصى للجلسات.

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

عند بلوغ هذا الحد، تفشل عملية تحويل الترميز، ويحتوي سجل FFmpeg على OpenEncodeSessionEx failed: out of memory (10). تذكر الرسالة الذاكرة، لكن رفض الوصول بسبب حد الجلسات يُرجع الرمز نفسه. لذلك تحقّق من عدد التدفقات المتزامنة قبل البحث عن تسرّب في VRAM. عملياً، يصل معظم المستخدمين إلى حد tone mapping أو إلى حد عرض النطاق الترددي للرفع قبل بلوغ الجلسة الثانية عشرة.

أثبت أن وحدة GPU تنفّذ تحويل الترميز، ولا تعتمد على الإعدادات

الإعداد المحفوظ ليس دليلاً. شغّل ملفاً تعرف أنه يفرض تحويل الترميز، ثم نفّذ 3 عمليات تحقق.

1. افتح Dashboard، ثم Playback. يجب أن تشير الجلسة النشطة إلى Transcoding، وأن تذكر السبب. إذا ظهرت Direct playing، فهذا يعني أنه لا يجري تحويل أي ترميز، وأنك تختبر الملف الخطأ.
2. افتح Dashboard، ثم Logs، وافتح أحدث سجل FFmpeg.Transcode. يظهر تحويل الترميز العتادي -hwaccel cuda و-hwaccel_output_format cuda في سطر الأوامر، مع استخدام h264_nvenc أو hevc_nvenc كمشفّر. إذا ظهر libx264 هناك، فأنت تنفّذ تحويل الترميز برمجياً، مهما ذكرت صفحة الإعدادات.
3. نفّذ nvidia-smi على المضيف أثناء استمرار التشغيل. يجب أن تظهر عملية من /usr/lib/jellyfin-ffmpeg/ffmpeg مع تخصيص ذاكرة من GPU، ويجب أن يعرض nvidia-smi dmon -s u قيماً غير صفرية في عمودي enc وdec.

نفّذ عملية التحقق الثالثة على المضيف، وليس داخل الحاوية. يعرض nvidia-smi داخل الحاوية عادةً قائمة عمليات فارغة، لأن الحاوية لا تستطيع رؤية معرّفات العمليات خارج مساحة الأسماء الخاصة بها، بينما تظل أرقام الاستخدام صحيحة. لا تعني قائمة العمليات الفارغة داخل الحاوية وجود عطل.

عندما يعود إلى المعالجة البرمجية من دون إبلاغك

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

يعني Cannot load libnvcuvid.so.1 في سجل التحويل أن مكتبة فك الترميز لم تُضمَّن إلى الحاوية. اضبط NVIDIA_DRIVER_CAPABILITIES=all وأعد إنشاء الحاوية، لأن تغيير البيئة يتطلب docker compose up -d لإعادة بنائها، بينما يحافظ إعادة التشغيل العادي على الإعدادات القديمة.

يعني No capable devices found الصادر من h264_nvenc أن FFmpeg وصل إلى مكتبة الترميز، لكنه لم يجد بطاقة قابلة للاستخدام. افحص docker compose exec jellyfin nvidia-smi مرة أخرى، لأن هذا يعني عادةً إزالة حجز الجهاز أو إعادة إنشاء الحاوية باستخدام ملف قديم.

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

إذا بدأ التحويل ثم توقف عند تشغيل محتوى 4K HDR بينما يعمل 1080p بشكل طبيعي، فالمشكلة هي الحد الأقصى لمعالجة تغيير النطاق الديناميكي، وليست تثبيتاً معطلاً. أكّد ذلك باستخدام عمود sm في nvidia-smi dmon -s u، ثم اخفض الدقة التي يطلبها العميل أو احتفظ بملفات 4K HDR على العملاء القادرين على تشغيلها مباشرة.

FAQ

لماذا يستمر Jellyfin في استخدام وحدة المعالجة المركزية بعد تفعيل NVENC؟

تحقق من أحدث سجل FFmpeg.Transcode ضمن Dashboard، ثم Logs. إذا ظهر فيه libx264، فهذا يعني أنه لم يُستخدم أي مسار عتادي، وهو ما يعني عادةً أن الحاوية لا تستطيع رؤية GPU، لذا شغّل docker compose exec jellyfin nvidia-smi للتأكد. إذا ظهر h264_nvenc مع استمرار انشغال وحدة المعالجة المركزية، فهذا يعني أن جانب فك الترميز يعمل برمجياً. يحدث ذلك عندما تفعّل برنامج ترميز لا تستطيع بطاقتك فك ترميزه، أو عندما تترك Enable hardware encoding معطلاً، فتنتقل نصف مراحل المعالجة فقط إلى GPU.

هل ما زلت أحتاج إلى السطر runtime: nvidia في Docker Compose؟

لا، إذا كان لديك مقطع deploy.resources.reservations.devices وإصدار حديث من Docker Compose. هذا المقطع هو الصيغة الحديثة لطلب الأجهزة ويؤدي المهمة نفسها. runtime: nvidia هو المسار الأقدم من حقبة nvidia-docker2. وما زال يعمل، كما أن المثال المنشور من Jellyfin يحتفظ بكليهما. الاحتفاظ بكليهما لا يسبب مشكلة. أما الاحتفاظ بـruntime: nvidia فقط، فيعني أنه يجب عليك أيضاً الاحتفاظ بـNVIDIA_VISIBLE_DEVICES=all، لأن هذا المسار لا يتضمن طلباً للأجهزة يقرأ منه قائمة الأجهزة، بل يأخذها من البيئة.

كم عدد التدفقات التي يمكن لـGPU واحد من NVIDIA تحويل ترميزها في الوقت نفسه؟

تحدد المصفوفة المنشورة من NVIDIA بطاقات GeForce بحد أقصى يبلغ 12 جلسة ترميز متزامنة اعتباراً من August 2026، بينما تُدرج بطاقات مراكز البيانات على أنها غير مقيّدة. نادراً ما يكون هذا الحد هو العامل الذي يوقفك. تعمل مطابقة النطاق الديناميكي من HDR إلى SDR على أنوية التظليل، وليس على NVENC، لذلك ستستهلك عدة تدفقات 4K HDR أنوية التظليل قبل وقت طويل من أهمية عدّاد الجلسات. قِس حالتك الفعلية باستخدام nvidia-smi dmon -s u وراقب عمود sm، لا عدد الجلسات.

هل يمكنني استخدام تحويل الترميز العتادي على VPS لا يحتوي على GPU؟

لا. يحتاج الترميز إلى كتلة NVENC الفعلية، ويعرض lspci -nn | grep -Ei "3d|display|vga" على VPS عادي محول عرض افتراضياً فقط من برنامج hypervisor. الحل العملي في خطة لا تحتوي على GPU هو إزالة عمليات تحويل الترميز بدلاً من ذلك: ارفع إعداد جودة العميل إلى Auto، واستخدم تطبيق عميل أصلياً بدلاً من المتصفح، وحوّل مسارات الترجمة المعتمدة على الصور إلى نص حتى لا تجبر النظام على إعادة ترميز الفيديو.

لماذا يتقطع تشغيل 4K HDR بينما يعمل تحويل ترميز 1080p بشكل جيد؟

يستخدم عبءا العمل الجزآن المختلفان من البطاقة. يقتصر تحويل ترميز 1080p SDR على فك الترميز والترميز، ويعمل كلاهما على العتاد ذي الوظيفة الثابتة. يضيف تدفق 4K HDR مطابقة النطاق الديناميكي، وهي مرشّح CUDA يعمل على أنوية التظليل، إضافةً إلى إطار أكبر بكثير لتحجيمه. يؤكد عرض nvidia-smi dmon -s u لقيمتي enc وdec منخفضتين بجوار sm مرتفعة ذلك، لأن هذا النمط يعني أن الكتل ذات الوظيفة الثابتة خاملة، وأن الأنوية متعددة الأغراض هي العامل المحدِّد.