إعداد تحويل 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. يثبّت الدليل الحالي من NVIDIA حزم toolkit أيضاً على إصدار واحد باستخدام متغير إصدار؛ أما ترك التثبيت دون هذا القيد، كما هنا، فيثبّت أحدث إصدار متاح في المستودع.

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 بوجود runtime.

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

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

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

من المفترض أن يطبع ذلك الجدول نفسه الذي طبعه المضيف. إذا فشل بدلاً من ذلك مع خطأ يفيد بتعذر تحديد device driver ذي إمكانات gpu، فهذا يعني أن Docker daemon لا يعرف nvidia runtime. لذلك شغّل أمر الإعداد مرة أخرى، ثم أعد تشغيل daemon.

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

هذه هي صيغة Compose الحديثة. وهي مبنية على المثال الذي تنشره Jellyfin، وتحدّد متغيرَي بيئة NVIDIA صراحةً.

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 فمهم لأن مجموعة الأدوات لا تربط مكتبات الفيديو داخل الحاوية إلا عند طلب قدرة الفيديو. وعندما يكون المتغير غير محدد، تكون القيم الافتراضية هي utility وcompute فقط. تحدّد صورة Jellyfin الرسمية هذا المتغير مسبقاً، لذلك يعمل السطر في تلك الصورة كإجراء احتياطي ضد أي إعداد يتجاوزه. وتوضح وثائق Jellyfin أنه يجب أن تضيفه بنفسك إذا أنشأت صورتك الخاصة. من دون قدرة الفيديو، يعمل CUDA بينما لا يعمل NVDEC، ويسجّل سجل التحويل Cannot load libnvcuvid.so.1. أما network_mode: host فهو الإعداد المستخدم في مثال Jellyfin الخاص بـNVIDIA. يذكر دليل حاوية Jellyfin أن استخدام شبكة المضيف اختياري، لكنه مطلوب لـDLNA. وإذا استخدمت شبكة bridge بدلاً منها، فعليك نشر المنفذ 8096/tcp ومنفذ الاكتشاف التلقائي 7359/udp بنفسك.

user: 1000:1000 هو السطر الأخير، ولا علاقة له بـGPU. فهو يحدد الملفات التي تستطيع Jellyfin قراءتها من وحدة التخزين التي تربطها بالوسائط. ويظهر عدم التطابق هنا كمكتبة فارغة، لا كخطأ في الصلاحيات. يشرح كيفية ربط 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 مستهلكاً بدرجة عالية.

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

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

ينطبق قيد آخر على الصفحة كلها: لا يُدعَم تسريع العتاد بالكامل إلا باستخدام البنية المضمّنة jellyfin-ffmpeg. تحذّر وثائق 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 والإصدارات الأحدث، مع أن متغيرات GM206 فقط من ذلك الجيل تدعمه، بينما يبدأ الترميز من Pascal والإصدارات الأحدث.
• AV1: فك الترميز بدءاً من Ampere والإصدارات الأحدث، باستثناء شريحة مراكز البيانات GA100؛ كما يسرد جدول برامج فك الترميز لدى NVIDIA معمارية Hopper من دون دعم لفك ترميز AV1. ويبدأ الترميز من Ada Lovelace والإصدارات الأحدث، وتدعمه Jellyfin بدءاً من 10.9.

يُعد الفصل الخاص بـHEVC 10-bit الأكثر تسبباً في المشكلات العملية. تفك بطاقة Maxwell المستندة إلى GM206 ترميز ملف 4K HDR باستخدام GPU، ثم لا تتمكن من ترميز خرج 10-bit، لذلك تستخدم Jellyfin ترميز H.264 ‏8-bit بدلاً منه. أما شرائح Maxwell الأخرى فلا تفك ترميز HEVC 10-bit عتادياً على الإطلاق. يظل خرج 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 مرتفعة إلى أن الحمل يقع على أنوية التظليل وليس على الوحدات ذات الوظائف الثابتة. لذلك تكون مطابقة النغمات أو تغيير الحجم أو دمج الترجمة في الفيديو هي التكلفة المحتملة. تعامل مع ذلك كمؤشر لا كدليل قاطع؛ إذ تعرّف NVIDIA استخدام GPU بأنه نسبة فترة العينة التي كان خلالها kernel واحد على الأقل قيد التنفيذ. لذلك تعني القراءة المرتفعة أن أنوية التظليل كانت مشغولة، ولا تعني أنها وصلت إلى أقصى طاقتها. كما يتعامل مسار CUDA مع Dolby Vision profile 5 باستخدام zero copy، وهذا مهم لأن الإطارات، من دون zero copy، تنتقل إلى ذاكرة النظام ثم تعود منها بين خطوات المرشح، وتستهلك هذه الرحلة ذهاباً وإياباً عرض النطاق الترددي مع كل إطار.

ما الذي يحدّه فعلياً سقف جلسات 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. عملياً، يصل معظم المستخدمين إلى حد تحويل النطاق الديناميكي أو حد سرعة الرفع لديهم قبل بلوغ الجلسة 12.

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

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

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

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

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

يفضّل Jellyfin مواصلة التشغيل. وعندما يصبح مسار الأجهزة غير متاح، ينتقل إلى المعالجة البرمجية بدلاً من إيقاف البث، لذلك فإن المؤشر الفعلي هو حمل CPU وسجل 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 مرة أخرى، لأن هذا يعني عادةً أن حجز الجهاز أُزيل أو أن الحاوية أُعيد إنشاؤها من ملف قديم.

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

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

FAQ

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

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

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

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

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

تحدد المصفوفة المنشورة من NVIDIA بطاقات GeForce باثنتي عشرة جلسة ترميز متزامنة حتى October 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 غالباً على فك الترميز والترميز، وكلاهما يعمل على العتاد ذي الوظيفة الثابتة عندما تدعم بطاقتك codec، إضافةً إلى أي تحجيم أو إزالة تشابك أو حرق للترجمة يحتاج إليه التدفق. يضيف تدفق 4K HDR مطابقة النطاق اللوني، وهي مرشّح CUDA يعمل على أنوية المظللات، إضافةً إلى إطار أكبر بكثير لتحجيمه. يشير ظهور nvidia-smi dmon -s u مع انخفاض enc وdec بجانب ارتفاع sm إلى هذا السبب، لأن وحدات الوظائف الثابتة تكون قليلة الاستخدام بينما تكون المظللات مشغولة. أعد تشغيل الملف مع تعطيل مطابقة النطاق اللوني، وسيحسم ذلك السبب.