Docker मध्ये Jellyfin NVIDIA हार्डवेअर ट्रान्सकोडिंग

तुम्ही काय तयार करत आहात

NVIDIA GPU वर Jellyfin hardware transcoding सुरू करण्यासाठी ठरावीक क्रमाने 4 पायऱ्या पूर्ण कराव्या लागतात. यापैकी केवळ शेवटची पायरी Jellyfin मध्ये केली जाते. Host driver लोड केलेला नसेल, तर container ला GPU दिसत नाही. Container ला GPU दिसत नसेल, तर Jellyfin तो वापरू शकत नाही. हा क्रम पाळा. त्यामुळे प्रत्येक अपयशाचे कारण कुठे शोधायचे हे स्पष्ट राहते.

1. Host वर NVIDIA driver install करा आणि त्याची खात्री nvidia-smi ने करा.
2. Docker ला container ला GPU देणे शक्य व्हावे यासाठी NVIDIA Container Toolkit install करा.
3. docker-compose.yml मध्ये Jellyfin service साठी GPU राखीव ठेवा आणि container ला तो दिसतो याची खात्री करा.
4. Jellyfin च्या playback settings मध्ये NVENC आणि NVDEC सुरू करा आणि प्रत्यक्ष playback मध्ये ते वापरले जात आहेत याची खात्री करा.

NVENC (NVIDIA encoder) आणि NVDEC (NVIDIA decoder) हे GPU card वरील fixed-function blocks आहेत. CUDA (compute unified device architecture) काम चालवणाऱ्या shader cores पासून हे वेगळ्या silicon वर असतात. हीच या पद्धतीची मुख्य उपयुक्तता आहे: software मध्ये अनेक CPU cores वापरणारा stream, CPU core च्या लहान भागासह GPU वरील dedicated hardware block वापरतो.

Direct play प्रत्येक transcode पेक्षा अधिक कार्यक्षम आहे, त्यामुळे प्रथम ते तपासा

यापैकी कोणतीही रचना करण्यापूर्वी, एखाद्या सहज दूर करता येणाऱ्या कारणामुळे transcoding होत आहे का ते शोधा. Client फाइल जशी आहे तशी प्ले करू शकत नसल्यास Jellyfin transcode करते. कारणे नेहमी मर्यादित असतात: video codec, audio codec, container format, image-based subtitles किंवा client ने मागितलेली bitrate limit.

Dashboard उघडा, त्यानंतर Playback निवडा आणि काहीतरी प्ले होत असताना सक्रिय session पाहा. Direct playing अशी खूण असलेले session फाइलमध्ये कोणताही बदल न करता पाठवते आणि जवळजवळ CPU वापरत नाही. Transcoding अशी खूण असलेले session Jellyfin ने निवडलेले कारण दाखवते. ते कारण दूर करा; त्यानंतर GPU ला अजिबात काम करावे लागणार नाही.

दोन बदल केल्यास बहुतेक transcode दूर होतात. Client app ची quality Auto किंवा कमाल मूल्यावर सेट करा. Client ने 4 Mbps मागितल्यास, फाइलमध्ये कोणताही codec असला तरी 20 Mbps फाइलचे पुन्हा encoding करावे लागते. त्यानंतर 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 वरच रेखाटावी लागतात आणि video stream चे पूर्ण re-encode करावे लागते. SRT मधील text subtitles स्वतंत्र track म्हणून client कडे पाठवता येतात आणि त्यासाठी CPU किंवा GPU संसाधन लागत नाही. शक्य असल्यास subtitle tracks चे text मध्ये रूपांतर करणे GPU घेण्यापेक्षा अधिक उपयुक्त ठरते. Server side च्या उर्वरित भागासाठी VPS वर Jellyfin media server चालवण्याचे मार्गदर्शक पहा.

बहुतेक VPS प्लॅनमध्ये GPU अजिबात नसतो

मानक VPS प्लॅनमध्ये GPU समाविष्ट नसतो. इतर कोणतेही नियोजन करण्यापूर्वी सर्व्हरवर हे चालवा.

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

सामान्य KVM VPS वर हा आदेश hypervisor कडून मिळणारे virtual display adapter दाखवतो किंवा उपयोगी माहिती दाखवत नाही. हे device व्हिडिओ encode करू शकत नाही. provider तुमच्या instance ला physical card pass through करतो किंवा त्यातील एक भाग देतो, तेव्हाच खरा GPU उपलब्ध होतो. अशा प्लॅनची किंमत त्यानुसार जास्त असते. GPU VPS साठी प्रत्यक्षात कोणत्या workloads साठी खर्च करणे योग्य आहे यामध्ये कोणासाठी GPU VPS योग्य आहे आणि कोणासाठी नाही हे स्पष्ट केले आहे.

GPU नसेल, तर direct play ला प्राधान्य द्या आणि software transcoding हा अपवादात्मक पर्याय माना. एक 1080p H.264 software transcode काही CPU cores वर जड असला तरी चालू शकतो. Tone mapping सह 4K HDR software transcode लहान VPS वर real time मध्ये पूर्ण होऊ शकत नाही. त्यामुळे CPU 100 percent वर सतत वापरला जात असताना stream मध्ये अडथळे येतात.

होस्टवर NVIDIA ड्रायव्हर इंस्टॉल करा

Jellyfin 10.11 मध्ये Linux साठी किमान NVIDIA ड्रायव्हर आवृत्ती 520.56.06 आवश्यक असल्याचे नमूद केले आहे. Ubuntu तुमच्यासाठी जुळणारे पॅकेज निवडणारे helper देते.

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

--gpgpu ड्रायव्हरची headless server flavour निवडते. Media server साठी हीच योग्य असते, कारण त्या मशीनवर 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 मध्ये ड्रायव्हर आवृत्ती आणि CUDA आवृत्ती असलेला तक्ता दिसतो. तुमचे 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 लोड झालेले नाही. नवीन इंस्टॉलेशनमध्ये याचे जवळजवळ नेहमीचे कारण म्हणजे तुम्ही अद्याप reboot केलेले नाही किंवा Secure Boot unsigned module लोड करण्यास नकार देत आहे. lsmod | grep nvidia वापरून module उपलब्ध आहे का ते तपासा.

NVIDIA Container Toolkit स्थापित करा

Driver मुळे host ला GPU वापरता येतो. तरीही Docker तो GPU container मध्ये पाठवत नाही, कारण container मध्ये device nodes किंवा driver libraries नसतात. Container सुरू होताना ही दोन्ही साधने उपलब्ध करून देणारा घटक म्हणजे NVIDIA Container Toolkit. 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 install करणे पुरेसे नाही, कारण runtime उपलब्ध आहे हे Docker ला सांगावे लागते.

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

nvidia-ctk runtime configure /etc/docker/daemon.json मध्ये nvidia runtime entry लिहिते. Restart करणे हा अनेकदा वगळला जाणारा टप्पा आहे. तो वगळल्यामुळे या संपूर्ण सेटअपमधील सर्वात सामान्य error निर्माण होतो. Jellyfin मध्ये बदल करण्यापूर्वी ही कार्यपद्धती तपासा.

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

यामुळे host वर दिसलेली तीच table दिसली पाहिजे. त्याऐवजी unable to select a device driver with gpu capabilities असा error आल्यास 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 मधील चार ओळींचे स्पष्टीकरण आवश्यक आहे. capabilities: [gpu] हे Compose साठीच आवश्यक आहे. ते वगळल्यास Compose सेवा GPU शिवाय सुरू करत नाही; त्याऐवजी सेवा नाकारतो. NVIDIA_DRIVER_CAPABILITIES=all महत्त्वाचे आहे, कारण video capability मागितल्यावरच toolkit video libraries container मध्ये mount करतो. Jellyfin च्या documentation मध्येही ही variable official image साठी आवश्यक असल्याचे नमूद केले आहे. ती नसल्यास CUDA कार्य करते, पण NVDEC कार्य करत नाही आणि transcode log मध्ये Cannot load libnvcuvid.so.1 नोंदवले जाते. network_mode: host Jellyfin च्या स्वतःच्या उदाहरणात वापरले आहे, कारण UDP port 7359 वरील client auto-discovery bridge network मधून कार्य करत नाही.

user: 1000:1000 ही शेवटची ओळ आहे. तिचा GPU शी काहीही संबंध नाही. तुमच्या media mount वरील कोणत्या files Jellyfin वाचू शकतो हे ती ठरवते. येथे mismatch असल्यास permissions error ऐवजी library रिकामी दिसते. PUID आणि PGID container user चे disk वरील files शी mapping कसे करतात या लेखात numbering चे स्पष्टीकरण आहे. तुम्ही याच्या बाजूला Docker Compose मध्ये Sonarr आणि Radarr stack चालवत असल्यास, तुम्ही आधी सेट केलेली हीच numbering येथे लागू होते.

बहुतेक ट्युटोरियल्स अजूनही runtime: nvidia का लिहितात

तुम्हाला आढळणाऱ्या जवळजवळ प्रत्येक मार्गदर्शिकेत जुना प्रकार दिसतो आणि तो चुकीचा नाही. हे त्यामागील इतिहासामुळे आहे. मूळ nvidia-docker2 पॅकेजने nvidia नावाचा OCI runtime नोंदवला होता. त्यामुळे कंटेनरमध्ये 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 ठेवण्यासाठी कोणताही अतिरिक्त खर्च नाही आणि त्यामुळे फाइल जुन्या Compose आवृत्त्यांवरही चालते. तुम्ही फक्त runtime: nvidia ठेवून deploy block काढून टाकत असाल, तर NVIDIA_VISIBLE_DEVICES=all ठेवणे आवश्यक आहे. जुना मार्ग कोणती devices inject करायची हे ठरवण्यासाठी environment variable वाचतो. त्याऐवजी वाचण्यासाठी त्याच्याकडे device request उपलब्ध नसते.

Jellyfin मध्ये NVIDIA हार्डवेअर transcoding सुरू करा

आतापर्यंतच्या कोणत्याही टप्प्याने Jellyfin ला हे कार्ड वापरण्यास सांगितलेले नाही. Dashboard उघडा, त्यानंतर Playback आणि मग Transcoding वर जा. Hardware acceleration म्हणून Nvidia NVENC निवडा. Enable hardware encoding निवडा. अन्यथा Jellyfin GPU वर decoding करते आणि त्यानंतर CPU वर encoding करते. या गोंधळात टाकणाऱ्या मधल्या स्थितीत GPU वर activity दिसते, पण CPU चा वापर तरीही जास्त राहतो.

Enable enhanced NVDEC decoder हे सध्याच्या NVDEC path आणि जुन्या CUVID path यांमध्ये निवड करते. हे सुरूच ठेवा. Dolby Vision हाताळण्यासाठी NVDEC वापरणे आवश्यक असल्याने ही setting सुरू असणे गरजेचे आहे.

Enable hardware decoding for अंतर्गत तुमचे card प्रत्यक्षात decode करू शकणारे codecsच निवडा. या setting मध्ये लोकांकडून सर्वाधिक चुका होतात. AV1 decoder नसलेल्या card वर AV1 निवडल्यास error message दिसत नाही. Jellyfin hardware decoding ची विनंती करते, पण ते उपलब्ध होत नाही. त्यानंतर decoding software मध्ये होते. त्यामुळे CPU वापर जास्त आणि GPU जवळजवळ idle दिसतो. Passthrough कधीच कार्यरत झाले नाही असेच हे दिसते.

संपूर्ण page साठी आणखी एक अट लागू आहे: hardware acceleration फक्त bundled jellyfin-ffmpeg build सोबत कार्य करते. तुम्ही FFmpeg path एखाद्या system FFmpeg कडे निर्देशित केल्यास acceleration अंशतः कार्य करते किंवा अजिबात कार्य करत नाही.

तुमच्या GPU पिढीतील कोणते codecs decode आणि encode करू शकतात

NVENC आणि NVDEC साठी Jellyfin ने दस्तऐवजीकरण केलेल्या मर्यादा पुढीलप्रमाणे आहेत. Decode आणि encode ही स्वतंत्र क्षमता आहेत. त्यामुळे एखाद्या card मध्ये यापैकी एक क्षमता असू शकते, पण दुसरी नसू शकते.

• H.264 8-bit: NVENC आणि NVDEC असलेला प्रत्येक NVIDIA GPU हे decode आणि encode दोन्ही करू शकतो.
• HEVC 8-bit: Maxwell second generation (GM206) आणि त्यानंतरच्या पिढ्यांपासून decode आणि encode उपलब्ध आहे.
• HEVC 10-bit: Maxwell second generation आणि त्यानंतरच्या पिढ्यांपासून decode उपलब्ध आहे; परंतु encode फक्त Pascal आणि त्यानंतरच्या पिढ्यांपासून उपलब्ध आहे.
• AV1: Ampere आणि त्यानंतरच्या पिढ्यांपासून decode उपलब्ध आहे; encode Ada Lovelace आणि त्यानंतरच्या पिढ्यांपासून उपलब्ध आहे.

HEVC 10-bit मधील हा फरक प्रत्यक्ष वापरात महत्त्वाचा ठरतो. Maxwell-era card तुमची 4K HDR file GPU वर decode करते, पण 10-bit output encode करू शकत नाही. त्यामुळे Jellyfin त्याऐवजी 8-bit H.264 encode करते. ते अद्याप योग्य प्रकारे play होते आणि बहुतेक clients साठी हीच योग्य निवड आहे. तुमच्याकडे कोणते card आहे याची पर्वा न करता, 2026 मध्ये AV1 encode क्वचितच उपयुक्त ठरते. याचे कारण client-side AV1 decode support अजूनही मर्यादित आहे. आधीच अडचण येत असलेल्या client पर्यंत सामग्री पोहोचवण्यासाठी transcode करावे लागते.

Tone mapping मुळे GPU वरचा भार शांतपणे पुन्हा वाढतो

HDR (high dynamic range) ते SDR (standard dynamic range) tone mapping ही सेटिंग GPU वरील उपलब्ध क्षमता का संपवते, याचे कारण तिची रचना आहे. Decode हे NVDEC वर चालते. Encode हे NVENC वर चालते. Tone mapping मात्र यापैकी कोणत्याही घटकावर चालत नाही. ते shader cores वर चालणारे CUDA filter आहे. GPU मधील हाच सर्वसाधारण उपयोगाचा भाग compute कामे चालवतो. त्यामुळे tone mapping आवश्यक असलेल्या 4K HDR stream मध्ये decoder आणि encoder वापरले जातात आणि त्यासोबत shaders वर अतिरिक्त भार येतो.

Jellyfin च्या दस्तऐवजानुसार HEVC 10-bit decode करू शकणाऱ्या प्रत्येक NVIDIA GPU वर CUDA tone mapping उपलब्ध आहे. त्यामुळे 4K वर सातत्याने हा भार पेलू न शकणाऱ्या cards वरही हा checkbox दिसतो आणि कार्यरत राहतो. याचे लक्षण म्हणजे stream सुरू होतो, buffer होतो आणि स्थिर होत नाही; मात्र nvidia-smi नुसार encoder वरचा भार अत्यल्प असतो.

म्हणून shader load स्वतंत्रपणे पाहणे आवश्यक आहे.

nvidia-smi dmon -s u

यामुळे दर सेकंदाला एक ओळ छापली जाते. त्यात sm, enc आणि dec यांच्यासाठी स्वतंत्र columns असतात. sm ची संख्या जास्त आणि enc व dec कमी असल्यास fixed-function blocks वर कमी भार आहे आणि shaders bottleneck आहेत. त्यामुळे tone mapping, scaling किंवा subtitle burn-in यापैकी कोणत्या प्रक्रियेमुळे भार येत आहे ते स्पष्ट होते. CUDA path zero copy सह Dolby Vision profile 5 देखील हाताळतो. हे महत्त्वाचे आहे, कारण zero copy नसल्यास प्रत्येक filter step दरम्यान frames 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 ने August 2026 पर्यंत प्रकाशित केलेले matrix मधील आकडे आहेत; ते येथे घेतलेली मोजमापे नाहीत. कोणतेही मॉडेल असले तरी GeForce card वर एकाच वेळी चालणाऱ्या encode sessions ची मर्यादा 12 असते. ही मर्यादा silicon मध्ये नसून driver मध्ये असते. NVIDIA ने गेल्या काही वर्षांत ही मर्यादा एकापेक्षा जास्त वेळा वाढवली आहे. त्यामुळे जुन्या forum thread ऐवजी सध्याचा matrix पाहा. Engine count हा card नुसार प्रत्यक्ष बदलणारा घटक आहे: 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 हा पुरावा नाही. Transcode होण्यास निश्चितपणे भाग पाडणारी फाइल प्ले करा आणि त्यानंतर तीन तपासण्या करा.

1. Dashboard उघडा आणि नंतर Playback निवडा. Active session मध्ये Transcoding असे दिसले पाहिजे आणि त्याचे कारणही नमूद केलेले असले पाहिजे. Direct playing असे दिसत असल्यास काहीही transcode होत नाही आणि तुम्ही चुकीच्या फाइलची चाचणी करत आहात.
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 ची मूल्ये शून्यापेक्षा जास्त दिसली पाहिजेत.

तिसरी तपासणी container च्या आत नव्हे, तर host वर करा. Container च्या आत nvidia-smi चालवल्यास सहसा process list रिकामी दिसते, कारण container ला त्याच्या स्वतःच्या namespace बाहेरील process IDs दिसत नाहीत. मात्र utilisation ची आकडेवारी तरीही योग्य दिसते. Container च्या आत रिकामी process list दिसणे ही त्रुटी नाही.

सूचना न देता software कडे fallback होताना

Jellyfin प्लेबॅक सुरू ठेवण्याला प्राधान्य देते. Hardware path उपलब्ध नसल्यास stream अयशस्वी करण्याऐवजी ते software कडे fallback होते. त्यामुळे योग्य संकेत error banner नसून CPU load आणि FFmpeg log हे आहेत.

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 stale file वापरून पुन्हा तयार केले गेले आहे.

GPU वापर कमी असताना CPU वापर जास्त असल्यास decode बाजू शांतपणे अयशस्वी होत आहे. तुमच्या generation ला decode करता न येणारे codecs untick करा. त्यानंतर तीच file पुन्हा play करा आणि -hwaccel cuda दिसते का हे पाहण्यासाठी FFmpeg log पुन्हा तपासा.

1080p व्यवस्थित चालत असताना 4K HDR वर सुरू झालेला transcode नंतर थांबत असल्यास ही tone-mapping ceiling आहे; install खराब झालेले नाही. nvidia-smi dmon -s u मधील sm column तपासून याची खात्री करा. त्यानंतर client ने मागितलेले resolution कमी करा किंवा 4K HDR files direct play करू शकणाऱ्या clients वरच ठेवा.

FAQ

Jellyfin मध्ये NVENC सक्षम केल्यानंतरही CPU चा वापर का होत राहतो?

Dashboard, त्यानंतर Logs अंतर्गत असलेला नवीनतम FFmpeg.Transcode log तपासा. त्यात libx264 दिसत असल्यास hardware path अजिबात वापरला गेलेला नाही. याचा सामान्य अर्थ container ला GPU दिसत नाही. याची खात्री करण्यासाठी docker compose exec jellyfin nvidia-smi चालवा. त्यात h264_nvenc दिसत असल्यास, पण CPU अजूनही व्यस्त असल्यास, decode भाग software मध्ये चालू आहे. तुम्ही तुमचे card decode करू शकत नसलेला codec निवडल्यास किंवा Enable hardware encoding बंद राहिल्यास असे होते. त्यामुळे pipeline चा केवळ अर्धा भाग GPU वर गेला आहे.

Docker Compose मध्ये runtime: nvidia line अजूनही आवश्यक आहे का?

तुमच्याकडे 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 साठी कोणतीही मर्यादा नसल्याचे नमूद केले आहे. ही मर्यादा क्वचितच खरी अडचण ठरते. HDR ते SDR tone mapping हे NVENC वर न होता shader cores वर चालते. त्यामुळे session counter महत्त्वाचा होण्यापूर्वीच काही 4K HDR streams shader cores पूर्णपणे वापरू शकतात. nvidia-smi dmon -s u वापरून तुमच्या परिस्थितीचे मोजमाप करा आणि session count ऐवजी sm column वर लक्ष ठेवा.

GPU नसलेल्या VPS वर hardware transcoding वापरता येईल का?

नाही. Encoding साठी प्रत्यक्ष NVENC block आवश्यक असतो. Standard VPS वर lspci -nn | grep -Ei "3d|display|vga" चालवल्यास hypervisor कडून मिळणारा केवळ virtual display adapter दिसतो. GPU नसलेल्या plan वर व्यावहारिक उपाय म्हणजे transcodes टाळणे. त्यासाठी client ची quality setting Auto वर वाढवा, browser ऐवजी native client app वापरा आणि image-based subtitle tracks चे text मध्ये रूपांतर करा, जेणेकरून video पुन्हा encode करावा लागू नये.

1080p transcode व्यवस्थित होत असताना 4K HDR मध्ये stutter का होतो?

दोन्ही workload 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 मध्ये enc आणि dec कमी, पण sm जास्त दिसत असल्यास याची पुष्टी होते. याचा अर्थ fixed-function blocks निष्क्रिय आहेत आणि general-purpose cores ही मर्यादा ठरत आहेत.