Docker میں Jellyfin NVIDIA hardware transcoding کیسے کریں

آپ کیا بنا رہے ہیں

NVIDIA GPU پر Jellyfin hardware transcoding چار مراحل پر مشتمل ہے، اور ان میں صرف آخری مرحلہ Jellyfin کے اندر ہوتا ہے۔ اگر host driver نے GPU load نہیں کیا تو container اسے نہیں دیکھ سکتا۔ اگر container GPU کو نہیں دیکھ سکتا تو Jellyfin اسے استعمال نہیں کر سکتا۔ اسی ترتیب سے کام کریں، تاکہ ہر failure کی واضح جگہ معلوم ہو۔

1. Host پر NVIDIA driver install کریں، پھر nvidia-smi سے اس کی تصدیق کریں۔
2. NVIDIA Container Toolkit install کریں، تاکہ Docker کسی container کو GPU دے سکے۔
3. docker-compose.yml میں Jellyfin service کے لیے GPU reserve کریں، پھر تصدیق کریں کہ container اسے دیکھ رہا ہے۔
4. Jellyfin کی اپنی playback settings میں NVENC اور NVDEC فعال کریں، پھر تصدیق کریں کہ حقیقی playback میں یہ استعمال ہو رہے ہیں۔

NVENC (NVIDIA encoder) اور NVDEC (NVIDIA decoder) card پر موجود fixed-function blocks ہیں۔ یہ shader cores سے الگ silicon ہیں، جبکہ shader cores CUDA (compute unified device architecture) کا کام چلاتے ہیں۔ یہ علیحدگی ہی اس configuration کی بنیادی وجہ ہے: software میں ایسا stream جو CPU کے کئی cores استعمال کرتا ہے، GPU کے ایک dedicated hardware block کے ساتھ CPU کے ایک core کا صرف معمولی حصہ استعمال کرتا ہے۔

ہر transcoding سے پہلے Direct play کو ترجیح دیں، اس لیے پہلے یہی جانچیں

اس میں سے کچھ بھی configure کرنے سے پہلے معلوم کریں کہ آیا آپ کسی ایسی وجہ سے transcoding کر رہے ہیں جسے آسانی سے دور کیا جا سکتا ہے۔ Jellyfin اس وقت transcode کرتا ہے جب client فائل کو اسی حالت میں چلا نہیں سکتا۔ وجہ ہمیشہ مختصر فہرست میں سے ایک ہوتی ہے: video codec، audio codec، container format، image-based subtitles، یا وہ bitrate limit جس کی client نے درخواست کی ہو۔

Dashboard کھولیں، پھر Playback پر جائیں، اور کچھ چلتے وقت active session کو monitor کریں۔ Direct playing کے طور پر نشان زد session فائل کو بغیر تبدیلی کے بھیجتا ہے اور تقریباً کوئی CPU استعمال نہیں کرتا۔ Transcoding کے طور پر نشان زد session وہ وجہ دکھاتا ہے جس کی بنا پر Jellyfin نے یہ طریقہ منتخب کیا۔ وہ وجہ دور کر دیں، تو GPU کو بالکل چلانے کی ضرورت نہیں پڑے گی۔

دو تبدیلیاں زیادہ تر transcodes ختم کر دیتی ہیں۔ Client app کی quality کو Auto یا maximum پر set کریں، کیونکہ 4 Mbps کی درخواست کرنے والا client، فائل میں کوئی بھی codec ہونے کے باوجود، 20 Mbps فائل کو دوبارہ encode کرنے پر مجبور کرتا ہے۔ پھر browser tab کے بجائے native client app استعمال کریں، کیونکہ browser آپ کے پاس موجود سب سے محدود player ہوتا ہے، جبکہ اسی TV پر native app اکثر اسی فائل کو Direct play کر دے گی۔

Image-based subtitles وہ استثنا ہیں جنہیں کوئی client setting درست نہیں کر سکتی۔ Blu-ray rip کے PGS subtitles اور DVD rip کے VOBSUB تصاویر ہوتی ہیں، اس لیے انہیں خود video پر draw کرنا پڑتا ہے، جس کا مطلب video stream کی مکمل re-encode ہے۔ SRT میں موجود text subtitles الگ track کے طور پر client کو بھیجے جاتے ہیں اور کوئی اضافی لاگت نہیں رکھتے۔ جہاں ممکن ہو، subtitle tracks کو text میں convert کرنا GPU سے زیادہ فائدہ مند ہے۔ Server side کے باقی حصے کے لیے VPS پر Jellyfin media server چلانے کی guide دیکھیں۔

زیادہ تر VPS plans میں GPU بالکل نہیں ہوتا

Standard VPS plans میں GPU شامل نہیں ہوتا۔ کوئی بھی منصوبہ بندی کرنے سے پہلے server پر یہ command چلائیں۔

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

عام KVM VPS پر یہ hypervisor کا virtual display adapter دکھاتا ہے، یا کوئی مفید output نہیں دیتا۔ یہ device video encode نہیں کر سکتا۔ حقیقی GPU صرف اس وقت دستیاب ہوتا ہے جب provider آپ کے instance کو physical card براہِ راست دے، یا اس کا ایک حصہ مختص کرے۔ ایسے plans کی قیمت بھی اسی کے مطابق ہوتی ہے۔ کون سے workloads کے لیے GPU VPS کی قیمت دینا واقعی مناسب ہے میں بتایا گیا ہے کہ کن صارفین کے لیے یہ موزوں ہے اور کن کے لیے نہیں۔

اگر GPU موجود نہ ہو تو direct play کو ترجیح دیں اور software transcoding کو غیر معمولی صورت سمجھیں۔ ایک 1080p H.264 software transcode چند CPU cores پر بھاری ضرور ہوتا ہے، لیکن چل سکتا ہے۔ tone mapping کے ساتھ 4K HDR software transcode کو چھوٹا VPS real time میں مکمل نہیں کر سکتا۔ اس لیے stream رک رک کر چلتی ہے، جبکہ CPU 100 percent استعمال پر پہنچا رہتا ہے۔

میزبان پر NVIDIA ڈرائیور انسٹال کریں

Jellyfin 10.11 کی دستاویزات کے مطابق Linux پر NVIDIA ڈرائیور کا کم از کم ورژن 520.56.06 ہونا چاہیے۔ Ubuntu ایسا helper فراہم کرتا ہے جو آپ کے لیے مطابقت رکھنے والا package منتخب کرتا ہے۔

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

--gpgpu ڈرائیور کا headless server flavour منتخب کرتا ہے۔ Media server کے لیے یہی flavour مناسب ہے، کیونکہ اس سرور پر desktop موجود نہیں ہوتا۔ list command آپ کے لیے دستیاب branches دکھاتی ہے۔ آپ کسی branch کو نام کے ذریعے منتخب کر سکتے ہیں، مثلاً sudo ubuntu-drivers install --gpgpu nvidia:570-server۔ وہی branch استعمال کریں جو list command نے حقیقت میں دکھائی ہو، نہ کہ یہاں لکھی ہوئی branch۔

Server flavour ہمیشہ nvidia-smi انسٹال نہیں کرتا۔ منتخب کردہ branch کے لیے مطابقت رکھنے والا utils package بھی انسٹال کریں، مثلاً sudo apt install nvidia-utils-570-server۔ پھر ڈرائیور چیک کریں۔

nvidia-smi

درست نتیجے میں header کے اندر driver version اور CUDA version والی table، نام کے ساتھ آپ کا card، اور خالی process list دکھائی دیتی ہے۔ یہاں دو مسائل عام ہیں۔ nvidia-smi: command not found کا مطلب ہے کہ utils package موجود نہیں، ڈرائیور غائب نہیں۔ NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver کا مطلب ہے کہ kernel module load نہیں ہوا۔ نئی انسٹالیشن میں اس کی تقریباً ہمیشہ وجہ یہ ہوتی ہے کہ آپ نے ابھی reboot نہیں کیا، یا Secure Boot unsigned module کو load ہونے سے روک رہا ہے۔ lsmod | grep nvidia سے تصدیق کریں کہ module موجود ہے۔

NVIDIA Container Toolkit انسٹال کریں

Driver سے host کو GPU استعمال کرنے کی اجازت ملتی ہے۔ لیکن Docker پھر بھی اسے container کے اندر فراہم نہیں کرے گا، کیونکہ container میں نہ device nodes ہوتے ہیں اور نہ driver libraries۔ NVIDIA Container Toolkit وہ جزو ہے جو container شروع ہوتے وقت دونوں فراہم کرتا ہے۔ یہ Debian اور Ubuntu کے لیے NVIDIA کے اپنے installation commands ہیں۔

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

Package انسٹال کرنا کافی نہیں، کیونکہ Docker کو یہ بتانا ضروری ہے کہ runtime موجود ہے۔

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

nvidia-ctk runtime configure، /etc/docker/daemon.json میں nvidia runtime entry لکھتا ہے۔ Restart وہ مرحلہ ہے جسے لوگ اکثر چھوڑ دیتے ہیں، اور اسے چھوڑنے سے اس پورے setup کی سب سے عام error پیدا ہوتی ہے۔ Jellyfin میں تبدیلی کرنے سے پہلے plumbing کو test کریں۔

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

اس سے وہی table دکھنی چاہیے جو host پر دکھائی گئی تھی۔ اگر اس کے بجائے یہ error آئے کہ gpu capabilities کے ساتھ device driver منتخب نہیں کیا جا سکتا، تو Docker daemon کو nvidia runtime کے بارے میں معلوم نہیں ہے۔ Configure command دوبارہ چلائیں اور daemon کو restart کریں۔

Docker Compose میں Jellyfin container کو GPU دیں

یہ جدید 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]

اسے شروع کریں اور براہِ راست container سے تصدیق کریں۔

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

اگر یہ container کے اندر سے driver table دکھاتا ہے تو GPU درست طور پر pass through ہو چکا ہے، اور باقی ہر مسئلہ Jellyfin کی setting سے متعلق ہے۔

اس file میں موجود چار lines کی وضاحت ضروری ہے۔ capabilities: [gpu] خود Compose کے لیے لازم ہے۔ اسے چھوڑنے پر Compose سروس کو GPU کے بغیر شروع نہیں کرتا بلکہ سروس مسترد کر دیتا ہے۔ NVIDIA_DRIVER_CAPABILITIES=all اس لیے اہم ہے کہ toolkit صرف اسی وقت video libraries کو container میں mount کرتا ہے جب video capability کی درخواست کی جائے۔ Jellyfin کی documentation میں بھی اس variable کو official image کے لیے لازم قرار دیا گیا ہے۔ اس کے بغیر CUDA کام کرتا ہے، لیکن NVDEC کام نہیں کرتا، اور transcode log میں Cannot load libnvcuvid.so.1 ظاہر ہوتا ہے۔ network_mode: host وہ setting ہے جو Jellyfin کی اپنی مثال میں استعمال ہوتی ہے، کیونکہ UDP port 7359 پر client auto-discovery bridge network کے ذریعے برقرار نہیں رہتی۔

user: 1000:1000 آخری setting ہے، اور اس کا GPU سے کوئی تعلق نہیں۔ یہ طے کرتی ہے کہ Jellyfin آپ کے media mount پر موجود کن files کو پڑھ سکتا ہے۔ یہاں mismatch ہونے پر permissions error کے بجائے library خالی دکھائی دیتی ہے۔ PUID اور PGID کس طرح container user کو disk پر موجود files سے map کرتے ہیں میں numbering کی وضاحت ہے۔ اگر آپ اس کے ساتھ Docker Compose میں Sonarr اور Radarr stack چلاتے ہیں تو یہ وہی numbering ہے جو آپ پہلے ہی set کر چکے ہیں۔

زیادہ تر tutorials اب بھی runtime: nvidia کیوں لکھتی ہیں

آپ کو ملنے والی تقریباً ہر guide میں پرانی شکل دکھائی دیتی ہے، اور یہ غلط نہیں ہے۔ یہ تاریخی وجہ ہے۔ اصل nvidia-docker2 package نے nvidia نامی OCI runtime رجسٹر کیا تھا، اس لیے container میں GPU شامل کرنے کا واحد طریقہ --runtime=nvidia کے ساتھ NVIDIA_VISIBLE_DEVICES استعمال کرنا تھا۔ Docker 19.03 نے --gpus flag اور device-request API شامل کی۔ Compose کو اس تبدیلی کے مطابق آنے میں زیادہ وقت لگا، اور جب یہ تبدیلی آئی تو device request deploy.resources.reservations.devices کے تحت شامل ہوئی۔ زیادہ تر لوگوں نے اس key کو نظرانداز کرنا سیکھ لیا تھا، کیونکہ deploy پہلے Docker Swarm کے معنی رکھتا تھا۔

نتیجہ یہ ہے کہ آج دونوں شکلیں کام کرتی ہیں، اور Jellyfin کی شائع کردہ مثال میں دونوں ایک ساتھ موجود ہیں۔ runtime: nvidia برقرار رکھنے میں کوئی نقصان نہیں، اور اس سے file پرانے Compose versions میں بھی کام کرتی ہے۔ اگر آپ صرف runtime: nvidia برقرار رکھیں اور deploy block ہٹا دیں، تو NVIDIA_VISIBLE_DEVICES=all برقرار رکھنا ضروری ہے، کیونکہ legacy path یہ environment variable پڑھ کر طے کرتا ہے کہ کون سے devices شامل کرنے ہیں، اور اس کے بجائے پڑھنے کے لیے اس کے پاس کوئی device request نہیں ہوتی۔

Jellyfin میں NVIDIA hardware transcoding فعال کریں

اب تک کسی بھی مرحلے میں Jellyfin کو card استعمال کرنے کی ہدایت نہیں دی گئی۔ Dashboard، پھر Playback، اور پھر Transcoding پر جائیں۔ Hardware acceleration کو Nvidia NVENC پر سیٹ کریں۔ Enable hardware encoding منتخب کریں۔ بصورت دیگر Jellyfin GPU پر decode اور CPU پر encode کرے گا۔ اس درمیانی حالت میں GPU سرگرمی دکھاتا ہے، لیکن CPU پھر بھی زیادہ کام کرتا رہتا ہے۔

Enable enhanced NVDEC decoder موجودہ NVDEC path اور پرانے CUVID path کے درمیان انتخاب کرتا ہے۔ اسے فعال رہنے دیں۔ Dolby Vision کی processing کے لیے NVDEC استعمال کرنے کی خاطر یہ setting فعال ہونا ضروری ہے۔

Under Enable hardware decoding for کے تحت صرف وہ codecs منتخب کریں جنہیں آپ کا card واقعی decode کر سکتا ہے۔ یہی وہ setting ہے جس میں لوگ عموماً غلطی کرتے ہیں۔ ایسے card پر AV1 منتخب کرنے سے، جس میں AV1 decoder موجود نہ ہو، کوئی error message ظاہر نہیں ہوتا۔ Jellyfin hardware decode کی درخواست کرتا ہے، لیکن hardware decode دستیاب نہ ہونے پر software decoding پر واپس آ جاتا ہے۔ نتیجتاً CPU usage زیادہ اور GPU تقریباً idle رہتا ہے۔ یہ بالکل ایسا دکھائی دیتا ہے جیسے passthrough نے کام ہی نہ کیا ہو۔

پورے صفحے پر ایک اور پابندی بھی لاگو ہوتی ہے: hardware acceleration صرف bundled jellyfin-ffmpeg build کے ساتھ کام کرتی ہے۔ اگر آپ نے FFmpeg path کو system FFmpeg کی طرف مقرر کیا ہے تو acceleration جزوی ہوگی یا بالکل نہیں ہوگی۔

آپ کی GPU نسل کن codecs کو decode اور encode کر سکتی ہے

یہ وہ حدود ہیں جنہیں Jellyfin نے NVENC اور NVDEC کے لیے دستاویز کیا ہے۔ Decode اور encode الگ صلاحیتیں ہیں، اور کسی card میں ان میں سے ایک صلاحیت ہو سکتی ہے جبکہ دوسری نہ ہو۔

• H.264 8-bit: ہر NVIDIA GPU جس میں NVENC اور NVDEC دونوں موجود ہوں، اسے decode اور encode کر سکتا ہے۔
• HEVC 8-bit: Maxwell second generation (GM206) اور اس کے بعد کی نسلوں میں decode اور encode دستیاب ہے۔
• HEVC 10-bit: Maxwell second generation اور اس کے بعد کی نسلوں میں decode دستیاب ہے، لیکن encode صرف Pascal اور اس کے بعد کی نسلوں میں دستیاب ہے۔
• AV1: Ampere اور اس کے بعد کی نسلوں میں decode، جبکہ Ada Lovelace اور اس کے بعد کی نسلوں میں encode دستیاب ہے۔

HEVC 10-bit کی یہ تقسیم عملی طور پر سب سے زیادہ مسئلہ پیدا کرتی ہے۔ Maxwell دور کا card آپ کی 4K HDR فائل کو GPU پر decode کر لیتا ہے، لیکن 10-bit output کو encode نہیں کر سکتا۔ اس لیے Jellyfin اس کے بجائے 8-bit H.264 encode کرتا ہے۔ یہ پھر بھی چلتا ہے، اور زیادہ تر clients کے لیے یہی درست انتخاب ہے۔ 2026 میں آپ کے card سے قطع نظر AV1 encode شاذونادر ہی مطلوب ہوتا ہے، کیونکہ client-side AV1 decode support اب بھی محدود ہے، اور transcode ایسے client تک پہنچنے کے لیے موجود ہوتا ہے جو پہلے ہی playback میں دشواری کا سامنا کر رہا تھا۔

ٹون میپنگ خاموشی سے GPU پر دوبارہ بوجھ کیوں ڈالتی ہے

HDR (high dynamic range) سے SDR (standard dynamic range) tone mapping وہ setting ہے جو آپ کا GPU budget ختم کر دیتی ہے، اور اس کی وجہ architecture ہے۔ Decode، NVDEC پر چلتا ہے۔ Encode، NVENC پر چلتا ہے۔ Tone mapping دونوں میں سے کسی پر نہیں چلتی؛ یہ shader cores پر چلنے والا CUDA filter ہے۔ GPU کا یہی عمومی مقصد والا حصہ compute work بھی چلاتا ہے۔ اس لیے 4K HDR stream جسے tone mapping درکار ہو، decoder اور encoder دونوں استعمال کرتی ہے، اور اس کے علاوہ shaders پر بھی load ڈالتی ہے۔

Jellyfin کے مطابق CUDA tone mapping ہر اس NVIDIA GPU پر دستیاب ہے جو HEVC 10-bit decode کر سکتا ہے۔ اس کا مطلب ہے کہ یہ checkbox ان cards پر بھی ظاہر ہوتا ہے اور کام کرتا ہے جو اسے 4K پر مسلسل نہیں چلا سکتے۔ اس کی علامت ایسی stream ہے جو شروع ہوتی ہے، buffer کرتی ہے اور کبھی مستحکم نہیں ہوتی، جبکہ nvidia-smi کے مطابق encoder بمشکل مصروف ہوتا ہے۔

اسی لیے shader load کو الگ سے monitor کرنا ضروری ہے۔

nvidia-smi dmon -s u

یہ ہر second ایک line output کرتا ہے، جس میں sm، enc اور dec کے لیے الگ columns ہوتے ہیں۔ کم enc اور dec کے ساتھ sm کی بلند value اس بات کی علامت ہے کہ fixed-function blocks معمول کے مطابق کام کر رہے ہیں اور bottleneck shaders ہیں۔ اس صورت میں tone mapping، scaling یا subtitle burn-in آپ کے GPU resources استعمال کر رہا ہے۔ CUDA path Dolby Vision profile 5 کو zero copy کے ساتھ بھی handle کرتا ہے۔ یہ اہم ہے، کیونکہ zero copy کے بغیر frames filter steps کے درمیان system memory میں بھیجے جاتے ہیں اور پھر واپس لائے جاتے ہیں۔ اس round trip میں ہر frame پر bandwidth استعمال ہوتی ہے۔

صارف 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 card، ماڈل سے قطع نظر، زیادہ سے زیادہ 12 بیک وقت encode sessions تک محدود ہوتا ہے۔ یہ حد silicon کے بجائے driver میں نافذ ہوتی ہے، اور NVIDIA نے گزشتہ برسوں میں اسے ایک سے زیادہ مرتبہ بڑھایا ہے۔ اس لیے کسی پرانی forum thread کے بجائے موجودہ matrix دیکھیں۔ اصل تبدیلی engine count میں آتی ہے: GeForce RTX 5090 میں 3 NVENC engines ہیں، جبکہ GeForce RTX 4060 میں 1 ہیں۔ زیادہ engines کا مطلب زیادہ parallel encode throughput ہے، session ceiling میں اضافہ نہیں۔

یہ حد encode sessions گنتی ہے، اس لیے صرف transcoding streams شمار ہوتی ہیں۔ Direct play اور remuxing کبھی encode session شروع نہیں کرتے۔ اسی matrix میں L4 جیسے data center cards کو unrestricted درج کیا گیا ہے۔ GPU VPS plan عموماً data center card فراہم کرتا ہے، اس لیے یہ حد زیادہ تر home server کے لیے اہم ہے۔

جب آپ اس حد تک پہنچتے ہیں تو transcode ناکام ہو جاتا ہے اور FFmpeg log میں OpenEncodeSessionEx failed: out of memory (10) ظاہر ہوتا ہے۔ پیغام memory کا ذکر کرتا ہے، لیکن session-limit refusal بھی یہی code رپورٹ کرتا ہے۔ اس لیے VRAM leak تلاش کرنے سے پہلے اپنے concurrent stream count کی جانچ کریں۔ عملی طور پر زیادہ تر صارفین session twelve تک پہنچنے سے پہلے tone-mapping ceiling یا upload bandwidth کی حد سے ٹکرا جاتے ہیں۔

ثابت کریں کہ GPU واقعی transcoding کر رہا ہے، configuration پر بھروسا نہ کریں

محفوظ کی گئی setting ثبوت نہیں ہوتی۔ ایسی file چلائیں جس کے بارے میں آپ جانتے ہوں کہ وہ لازماً transcode کرواتی ہے، پھر یہ تین checks چلائیں۔

1. Dashboard کھولیں، پھر Playback کھولیں۔ فعال session میں Transcoding لکھا ہونا چاہیے، اور اس میں وجہ بھی درج ہونی چاہیے۔ اگر Direct playing لکھا ہو تو کچھ بھی transcode نہیں ہو رہا، اور آپ غلط file test کر رہے ہیں۔
2. Dashboard کھولیں، پھر Logs کھولیں، اور تازہ ترین FFmpeg.Transcode log کھولیں۔ hardware transcode میں command line پر -hwaccel cuda اور -hwaccel_output_format cuda نظر آنے چاہئیں، جبکہ encoder کے طور پر h264_nvenc یا hevc_nvenc درج ہونا چاہیے۔ اگر وہاں libx264 نظر آئے تو settings page کے دعوے سے قطع نظر transcoding software میں ہو رہی ہے۔
3. Playback جاری رہنے کے دوران host پر nvidia-smi چلائیں۔ /usr/lib/jellyfin-ffmpeg/ffmpeg کا کوئی process GPU memory مختص کیے ہوئے نظر آنا چاہیے، اور nvidia-smi dmon -s u میں enc اور dec columns کی values صفر سے زیادہ ہونی چاہئیں۔

یہ تیسرا check container کے اندر نہیں، host پر چلائیں۔ Container کے اندر nvidia-smi عموماً خالی process list دکھاتا ہے، کیونکہ وہ اپنی namespace سے باہر کے process IDs نہیں دیکھ سکتا، جبکہ utilisation numbers درست رہتی ہیں۔ Container کے اندر خالی process list آنا خرابی نہیں ہے۔

جب یہ آپ کو بتائے بغیر software پر واپس چلا جائے

Jellyfin پلے بیک جاری رکھنے کو ترجیح دیتا ہے۔ جب hardware path دستیاب نہ ہو تو یہ stream کو ناکام بنانے کے بجائے software پر منتقل ہو جاتا ہے۔ اس لیے درست اشارہ CPU load اور FFmpeg log ہیں، error banner نہیں۔

transcode log میں Cannot load libnvcuvid.so.1 کا مطلب ہے کہ decoder library کو container میں mount ہی نہیں کیا گیا۔ NVIDIA_DRIVER_CAPABILITIES=all سیٹ کریں اور container کو دوبارہ بنائیں، کیونکہ environment میں تبدیلی کے لیے docker compose up -d درکار ہوتا ہے۔ صرف restart کرنے سے پرانی settings برقرار رہتی ہیں۔

h264_nvenc سے حاصل ہونے والا No capable devices found اس وقت ظاہر ہوتا ہے جب FFmpeg encoder library تک پہنچ جائے، لیکن اسے کوئی قابلِ استعمال card نہ ملے۔ docker compose exec jellyfin nvidia-smi دوبارہ چیک کریں، کیونکہ عموماً اس کا مطلب ہوتا ہے کہ device reservation ہٹا دی گئی ہے یا container کو پرانی file سے دوبارہ بنایا گیا ہے۔

خاموش GPU کے ساتھ زیادہ CPU استعمال کا مطلب ہے کہ decode side خاموشی سے ناکام ہو رہی ہے۔ اپنی generation کے لیے ناقابلِ decode codecs کو untick کریں، پھر وہی file دوبارہ چلائیں اور FFmpeg log دوبارہ پڑھیں تاکہ معلوم ہو سکے کہ -hwaccel cuda ظاہر ہوتا ہے یا نہیں۔

اگر transcode شروع ہونے کے بعد 4K HDR پر رک جائے جبکہ 1080p درست چل رہا ہو تو یہ tone-mapping ceiling ہے، installation کی خرابی نہیں۔ nvidia-smi dmon -s u کے sm column سے اس کی تصدیق کریں۔ پھر یا تو client کی مطلوبہ resolution کم کریں، یا 4K HDR files ایسے clients پر رکھیں جو انہیں direct play کر سکتے ہوں۔

FAQ

Jellyfin میں NVENC فعال کرنے کے بعد بھی CPU کیوں استعمال کرتا ہے؟

Dashboard، پھر Logs کے تحت تازہ ترین FFmpeg.Transcode log دیکھیں۔ اگر اس میں libx264 دکھائی دے تو hardware path بالکل استعمال نہیں ہوا، جس کا عام مطلب یہ ہے کہ container کو GPU نظر نہیں آ رہا۔ تصدیق کے لیے docker compose exec jellyfin nvidia-smi چلائیں۔ اگر h264_nvenc دکھائی دے لیکن CPU پھر بھی مصروف ہو تو decode side software میں چل رہی ہے۔ ایسا اس وقت ہوتا ہے جب آپ نے ایسا codec منتخب کیا ہو جسے آپ کا card decode نہیں کر سکتا، یا Enable hardware encoding غیر فعال رہ گیا ہو، جس کی وجہ سے pipeline کا صرف نصف حصہ GPU پر منتقل ہوا۔

کیا Docker Compose میں runtime: nvidia لائن اب بھی درکار ہے؟

اگر آپ کے پاس deploy.resources.reservations.devices block اور موجودہ Docker Compose ہے تو نہیں۔ یہ block جدید device-request طریقہ ہے اور وہی کام کرتا ہے۔ runtime: nvidia، nvidia-docker2 دور کا پرانا طریقہ ہے۔ یہ اب بھی کام کرتا ہے، اور Jellyfin کی اپنی شائع کردہ مثال میں دونوں شامل ہیں۔ دونوں کو برقرار رکھنا بے ضرر ہے۔ صرف runtime: nvidia رکھنے کی صورت میں NVIDIA_VISIBLE_DEVICES=all بھی برقرار رکھنا ضروری ہے، کیونکہ اس طریقے میں device request نہیں ہوتا جسے پڑھا جا سکے، اور device list environment سے حاصل ہوتی ہے۔

ایک NVIDIA GPU بیک وقت کتنے streams کو transcode کر سکتا ہے؟

NVIDIA کی شائع کردہ matrix کے مطابق August 2026 تک GeForce cards کی حد بیک وقت بارہ encode sessions ہے، جبکہ data center cards کو unrestricted درج کیا گیا ہے۔ عموماً یہی حد آپ کے لیے رکاوٹ نہیں بنتی۔ HDR سے SDR tone mapping، NVENC کے بجائے shader cores پر چلتی ہے، اس لیے چند 4K HDR streams session counter اہم ہونے سے بہت پہلے shaders کو مکمل طور پر استعمال کر سکتی ہیں۔ nvidia-smi dmon -s u سے اپنی صورت حال کی پیمائش کریں اور session count کے بجائے sm column monitor کریں۔

کیا GPU کے بغیر VPS پر hardware transcoding استعمال کی جا سکتی ہے؟

نہیں۔ Encoding کے لیے physical NVENC block درکار ہوتا ہے، اور standard VPS پر lspci -nn | grep -Ei "3d|display|vga" hypervisor کا صرف virtual display adapter دکھاتا ہے۔ GPU-free plan پر عملی حل یہ ہے کہ transcodes ختم کریں: client کی quality setting کو Auto پر بڑھائیں، browser کے بجائے native client app استعمال کریں، اور image-based subtitle tracks کو text میں convert کریں تاکہ وہ video re-encode پر مجبور نہ کریں۔

1080p transcodes درست چلنے کے باوجود 4K HDR میں stutter کیوں ہوتا ہے؟

دونوں workloads card کے مختلف حصے استعمال کرتے ہیں۔ 1080p SDR transcode صرف decode اور encode پر مشتمل ہوتا ہے، اور دونوں fixed-function hardware پر چلتے ہیں۔ 4K HDR stream میں tone mapping شامل ہوتی ہے، جو shader cores پر چلنے والا CUDA filter ہے، نیز scale کرنے کے لیے frame بھی بہت بڑا ہوتا ہے۔ nvidia-smi dmon -s u میں low enc اور dec کے ساتھ high sm دکھائی دے تو اس کی تصدیق ہو جاتی ہے، کیونکہ اس pattern کا مطلب ہے کہ fixed-function blocks idle ہیں اور general-purpose cores حد بن گئے ہیں۔