Docker में Jellyfin NVIDIA hardware transcoding कैसे करें

आप क्या बना रहे हैं

NVIDIA GPU पर Jellyfin hardware transcoding चार चरणों की एक निश्चित प्रक्रिया है, और केवल अंतिम चरण Jellyfin के भीतर होता है। यदि host driver ने GPU को लोड नहीं किया है, तो container उसे नहीं देख सकता। यदि container GPU को नहीं देख सकता, तो Jellyfin उसका उपयोग नहीं कर सकता। इस क्रम का पालन करें, इससे किसी भी विफलता के कारण का पता लगाना आसान हो जाता है।

1. Host पर NVIDIA driver इंस्टॉल करें, फिर nvidia-smi के साथ इसकी पुष्टि करें।
2. NVIDIA Container Toolkit इंस्टॉल करें ताकि Docker container को GPU सौंप सके।
3. docker-compose.yml में Jellyfin service के लिए GPU को आरक्षित करें, फिर पुष्टि करें कि container उसे देख पा रहा है।
4. Jellyfin की playback settings में NVENC और NVDEC को चालू करें, फिर पुष्टि करें कि वास्तविक playback इनका उपयोग कर रहा है।

NVENC (NVIDIA encoder) और NVDEC (NVIDIA decoder) कार्ड पर स्थित fixed-function ब्लॉक्स हैं। ये उन shader cores से अलग सिलिकॉन हैं जो CUDA (compute unified device architecture) कार्य करते हैं। यह अलगाव ही इस प्रक्रिया का मुख्य लाभ है: जो stream software transcoding में कई CPU cores का उपयोग करती है, वह GPU पर केवल एक core का छोटा सा हिस्सा और एक समर्पित hardware block का उपयोग करती है।

Direct play हर transcode से बेहतर है, इसलिए सबसे पहले इसकी जाँच करें

इससे पहले कि आप इनमें से कुछ भी configure करें, यह पता लगाएँ कि क्या आप किसी ऐसे कारण से transcoding कर रहे हैं जिसे आसानी से हटाया जा सकता है। Jellyfin तब transcoding करता है जब client file को वैसे नहीं चला पाता जैसी वह है। इसका कारण हमेशा एक छोटी सूची में से ही होता है: video codec, audio codec, container format, image-based subtitles, या client द्वारा माँगी गई bitrate limit।

Dashboard खोलें, फिर Playback पर जाएँ, और कुछ चलते समय active session को देखें। Direct playing के रूप में चिह्नित session file को बिना बदले भेजता है और इसमें लगभग कोई CPU खर्च नहीं होता। Transcoding के रूप में चिह्नित session वह कारण दिखाता है जिसे Jellyfin ने चुना है। उस कारण को हटा दें और GPU को कभी भी चलने की आवश्यकता नहीं होगी।

दो बदलाव अधिकांश transcodes को हटा देते हैं। Client app की quality को Auto या maximum पर सेट करें, क्योंकि 4 Mbps माँगने वाला client 20 Mbps की file को re-encode करने के लिए मजबूर करता है, चाहे उसमें कोई भी codec हो। फिर browser tab के बजाय native client app का उपयोग करें, क्योंकि browser आपके पास मौजूद सबसे सीमित player है और उसी TV पर एक native app अक्सर वही file 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 में बदलना GPU से अधिक मूल्यवान है। सर्वर साइड का बाकी हिस्सा Jellyfin media server को VPS पर चलाने के लिए गाइड में शामिल है।

अधिकांश VPS प्लान में कोई GPU नहीं होता है

Standard VPS प्लान में GPU शामिल नहीं होता है। किसी भी अन्य योजना से पहले सर्वर पर इसे चलाकर देखें।

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

एक सामान्य KVM VPS पर यह hypervisor से एक virtual display adapter दिखाता है, या कुछ भी उपयोगी नहीं दिखाता है। वह device वीडियो encode नहीं कर सकता है। एक वास्तविक GPU तभी दिखाई देता है जब provider एक physical card को आपके instance के लिए pass-through करता है या उसका एक हिस्सा (slice) देता है, और उन प्लान की कीमत उसी अनुसार होती है। किन workloads के लिए GPU VPS का खर्च उठाना उचित है में बताया गया है कि किसे इसकी आवश्यकता है और किसे नहीं।

यदि GPU नहीं है, तो direct play का लक्ष्य रखें और software transcoding को एक दुर्लभ स्थिति मानें। एक single 1080p H.264 software transcode भारी होता है, लेकिन कुछ CPU cores पर इसे संभाला जा सकता है। tone mapping के साथ 4K HDR software transcode को एक छोटा VPS real-time में पूरा नहीं कर सकता है, इसलिए stream अटकती है जबकि CPU 100 प्रतिशत उपयोग पर स्थिर रहता है।

Host पर NVIDIA driver इंस्टॉल करना

Jellyfin 10.11 के दस्तावेज़ों के अनुसार Linux पर कम से कम 520.56.06 NVIDIA driver होना आवश्यक है। Ubuntu एक सहायक टूल प्रदान करता है जो आपके लिए सही पैकेज चुनता है।

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

--gpgpu ड्राइवर के headless server वर्शन को चुनता है, जो एक मीडिया सर्वर के लिए उपयुक्त है क्योंकि सर्वर पर कोई डेस्कटॉप वातावरण नहीं होता। list कमांड आपके लिए उपलब्ध branches को दिखाती है, और आप किसी एक को नाम से पिन कर सकते हैं, उदाहरण के लिए sudo ubuntu-drivers install --gpgpu nvidia:570-server। उस branch का उपयोग करें जो list कमांड में दिखाई गई है, न कि यहाँ लिखी गई branch का।

Server वर्शन हमेशा nvidia-smi को इंस्टॉल नहीं करता है। अपनी चुनी हुई branch के लिए संबंधित 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 module लोड नहीं हुआ है, जिसका अर्थ नए इंस्टॉलेशन पर लगभग हमेशा यह होता है कि आपने अभी तक सिस्टम को reboot नहीं किया है, या Secure Boot किसी unsigned module को लोड करने से मना कर रहा है। lsmod | grep nvidia के साथ पुष्टि करें कि मॉड्यूल मौजूद है।

NVIDIA Container Toolkit इंस्टॉल करना

Driver host को GPU का उपयोग करने की अनुमति देता है। Docker इसे container में नहीं भेजेगा, क्योंकि container में न तो device nodes होते हैं और न ही driver libraries। NVIDIA Container Toolkit वह घटक है जो container शुरू होने पर इन दोनों को inject करता है। ये Debian और Ubuntu के लिए NVIDIA के आधिकारिक इंस्टॉलेशन कमांड हैं।

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 वह चरण है जिसे लोग अक्सर छोड़ देते हैं, और इसे न करने से इस पूरे सेटअप में सबसे आम error आती है। Jellyfin को छूने से पहले plumbing का परीक्षण करें।

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

इसे वही table print करनी चाहिए जो host ने print की थी। यदि इसके बजाय यह error देता है कि gpu capabilities के साथ device driver का चयन नहीं किया जा सका, तो इसका मतलब है कि Docker daemon को nvidia runtime के बारे में जानकारी नहीं है। इसलिए, configure कमांड को फिर से चलाएं और daemon को restart करें।

Jellyfin container को Docker Compose में 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]

इसे start करें और सीधे container से पूछें।

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

यदि यह container के भीतर से driver table print करता है, तो GPU सही ढंग से pass-through हो गया है और बाकी बची समस्या Jellyfin की setting में है।

उस file की चार lines स्पष्टीकरण की मांग करती हैं। capabilities: [gpu] की आवश्यकता स्वयं Compose को होती है, और इसे न लिखने पर Compose service को start करने के बजाय मना कर देता है। 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 वह है जिसका उपयोग Jellyfin का अपना उदाहरण करता है, क्योंकि UDP port 7359 पर client auto-discovery bridge network पर काम नहीं करता है।

user: 1000:1000 अंतिम है, और इसका GPU से कोई लेना-देना नहीं है। यह तय करता है कि Jellyfin आपके media mount पर कौन सी files पढ़ सकता है, और यहाँ बेमेल होने पर permissions error के बजाय library खाली दिखाई देती है। PUID और PGID कैसे container user को disk पर मौजूद files से map करते हैं numbering को समझाता है, और यदि आप इसके साथ Docker Compose में Sonarr और Radarr stack चलाते हैं, तो यह वही numbering है जिसे आप पहले ही set कर चुके हैं।

ज्यादातर ट्यूटोरियल अभी भी runtime: nvidia क्यों लिखते हैं

पुराना तरीका आपको मिलने वाली लगभग हर गाइड में दिखाई देगा, और यह गलत नहीं है। यह इतिहास है। मूल nvidia-docker2 पैकेज ने nvidia नामक एक OCI runtime रजिस्टर किया था, इसलिए कंटेनर में GPU प्राप्त करने का एकमात्र तरीका --runtime=nvidia के साथ NVIDIA_VISIBLE_DEVICES का उपयोग करना था। Docker 19.03 ने --gpus फ्लैग और एक उचित device-request API को जोड़ा। Compose को इसे अपनाने में अधिक समय लगा, और जब उसने ऐसा किया, तो device request deploy.resources.reservations.devices के अंतर्गत आया, एक ऐसी key जिसे ज्यादातर लोगों ने अनदेखा करना सीख लिया था क्योंकि deploy का मतलब Docker Swarm हुआ करता था।

परिणाम यह है कि आज दोनों तरीके काम करते हैं, और Jellyfin का प्रकाशित उदाहरण दोनों को एक साथ रखता है। runtime: nvidia को रखने में कोई नुकसान नहीं है और यह फाइल को पुराने Compose वर्ज़न पर भी काम करने योग्य बनाता है। यदि आप केवल runtime: nvidia रखते हैं और deploy ब्लॉक को हटा देते हैं, तो आपको NVIDIA_VISIBLE_DEVICES=all को बनाए रखना होगा, क्योंकि वह पुराना पाथ यह तय करने के लिए environment variable को पढ़ता है कि कौन से डिवाइस इंजेक्ट करने हैं और इसके बजाय पढ़ने के लिए कोई device request मौजूद नहीं होता है।

Jellyfin में NVIDIA हार्डवेयर ट्रांसकोडिंग चालू करना

अभी तक 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 बिल्ड के साथ काम करता है। यदि आपने FFmpeg पाथ को सिस्टम FFmpeg पर पॉइंट किया है, तो आपको आंशिक या कोई एक्सेलेरेशन नहीं मिलेगा।

आपकी GPU जनरेशन किन codecs को decode और encode कर सकती है

ये वे सीमाएं हैं जिन्हें Jellyfin ने NVENC और NVDEC के लिए प्रलेखित किया है। Decode और encode अलग-अलग क्षमताएं हैं, और एक कार्ड में एक हो सकती है जबकि दूसरी नहीं।

• H.264 8-bit: NVENC और NVDEC वाले हर NVIDIA GPU में इसे decode और encode करने की क्षमता होती है।
• HEVC 8-bit: Maxwell दूसरी जनरेशन (GM206) और उसके बाद के कार्ड्स में decode और encode की सुविधा है।
• HEVC 10-bit: Maxwell दूसरी जनरेशन और उसके बाद के कार्ड्स में decode की सुविधा है, लेकिन encode केवल Pascal और उसके बाद के कार्ड्स में ही संभव है।
• AV1: Ampere और उसके बाद के कार्ड्स में decode, और Ada Lovelace और उसके बाद के कार्ड्स में encode की सुविधा है।

HEVC 10-bit का विभाजन वह बिंदु है जो व्यावहारिक रूप से समस्या पैदा करता है। Maxwell-युग का कार्ड आपके 4K HDR फ़ाइल को GPU पर decode तो कर लेता है, लेकिन 10-bit आउटपुट को encode नहीं कर पाता, इसलिए Jellyfin इसके बजाय 8-bit H.264 को encode करता है। यह अभी भी प्ले होता है, और अधिकांश क्लाइंट्स के लिए वैसे भी यही सही विकल्प है। 2026 में आपके कार्ड की परवाह किए बिना AV1 encode की आवश्यकता शायद ही कभी पड़ती है, क्योंकि क्लाइंट-साइड AV1 decode सपोर्ट अभी भी सीमित है और transcode का उपयोग ही तब किया जाता है जब क्लाइंट पहले से ही कंटेंट चलाने में संघर्ष कर रहा हो।

टोन मैपिंग चुपचाप GPU को क्यों ओवरलोड कर देती है

HDR (high dynamic range) से SDR (standard dynamic range) टोन मैपिंग वह सेटिंग है जो आपके GPU बजट को खत्म कर देती है, और इसका कारण आर्किटेक्चरल है। डिकोड NVDEC पर चलता है। एनकोड NVENC पर चलता है। टोन मैपिंग इनमें से किसी पर नहीं चलती: यह shader cores पर चलने वाला एक CUDA फिल्टर है, जो GPU का वही सामान्य-उद्देश्य वाला हिस्सा है जो compute कार्य करता है। इसलिए, एक 4K HDR स्ट्रीम जिसे टोन मैपिंग की आवश्यकता होती है, वह डिकोडर और एनकोडर का उपयोग करती है, और इसके ऊपर shaders पर लोड डालती है।

Jellyfin, CUDA टोन मैपिंग को हर उस NVIDIA GPU पर उपलब्ध बताता है जो HEVC 10-bit को डिकोड कर सकता है। इसका मतलब है कि चेकबॉक्स उन कार्ड्स पर भी दिखाई देता है और काम करता है जो 4K पर इसे बनाए रखने में सक्षम नहीं हैं। इसका लक्षण एक ऐसी स्ट्रीम है जो शुरू होती है, बफर करती है, और कभी स्थिर नहीं होती, जबकि nvidia-smi रिपोर्ट करता है कि एनकोडर मुश्किल से ही व्यस्त है।

यही कारण है कि shader लोड को अलग से देखना महत्वपूर्ण है।

nvidia-smi dmon -s u

यह कमांड प्रति सेकंड एक लाइन प्रिंट करती है जिसमें sm, enc और dec के लिए अलग-अलग कॉलम होते हैं। एक उच्च sm नंबर के साथ कम enc और dec का मतलब है कि फिक्स्ड-फंक्शन ब्लॉक खाली बैठे हैं और shaders ही बाधा (bottleneck) हैं, इसलिए टोन मैपिंग, स्केलिंग, या सबटाइटल बर्न-इन ही वह प्रक्रिया है जो आपके संसाधन खर्च कर रही है। CUDA पाथ Dolby Vision profile 5 को भी zero copy के साथ हैंडल करता है, जो महत्वपूर्ण है क्योंकि zero copy के बिना फ्रेम्स फिल्टर चरणों के बीच सिस्टम मेमोरी में जाते हैं और वापस आते हैं, और वह राउंड ट्रिप हर एक फ्रेम पर बैंडविड्थ की लागत बढ़ाती है।

Consumer NVENC session cap वास्तव में क्या सीमित करता है

[
  {
    "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
  }
]

ये अगस्त 2026 तक NVIDIA द्वारा प्रकाशित मैट्रिक्स के आंकड़े हैं, न कि यहाँ किए गए मापन। GeForce कार्ड का मॉडल चाहे जो भी हो, इसमें अधिकतम 12 समवर्ती (concurrent) encode sessions की सीमा होती है। यह सीमा सिलिकॉन के बजाय ड्राइवर में होती है, और NVIDIA ने वर्षों में इसे कई बार बढ़ाया है, इसलिए पुराने फोरम थ्रेड्स के बजाय वर्तमान मैट्रिक्स को देखें। इंजन की संख्या वह हिस्सा है जो वास्तव में कार्ड के साथ बदलता है: GeForce RTX 5090 में 3 NVENC इंजन होते हैं, जबकि GeForce RTX 4060 में 1 इंजन होते हैं। अधिक इंजन का मतलब अधिक समानांतर (parallel) encode थ्रूपुट है, न कि सत्रों की उच्च सीमा।

यह सीमा encode sessions की गिनती करती है, इसलिए यह केवल transcoding streams को ही सीमित करती है। Direct play और remuxing कभी भी encode session नहीं खोलते हैं। L4 जैसे डेटा सेंटर कार्ड उसी मैट्रिक्स में अप्रतिबंधित (unrestricted) के रूप में सूचीबद्ध हैं, और GPU VPS प्लान में आमतौर पर आपको डेटा सेंटर कार्ड ही मिलता है, इसलिए यह सीमा मुख्य रूप से होम-सर्वर के लिए चिंता का विषय है।

जब आप इस सीमा तक पहुँचते हैं, तो transcode विफल हो जाता है और FFmpeg लॉग में OpenEncodeSessionEx failed: out of memory (10) दिखाई देता है। संदेश में मेमोरी का उल्लेख होता है, लेकिन session-limit के कारण इनकार (refusal) भी यही कोड रिपोर्ट करता है, इसलिए VRAM लीक की जाँच करने से पहले अपनी समवर्ती स्ट्रीम की संख्या देखें। व्यवहार में, अधिकांश लोग सत्र बारह तक पहुँचने से पहले ही tone-mapping की सीमा या अपनी अपलोड बैंडविड्थ की सीमा तक पहुँच जाते हैं।

यह सिद्ध करें कि GPU transcoding कर रहा है, कॉन्फ़िगरेशन पर भरोसा न करें

सहेजी गई सेटिंग प्रमाण नहीं है। ऐसी फ़ाइल चलाएँ जिसके बारे में आप जानते हैं कि वह transcoding को बाध्य करती है, फिर तीन जाँचें करें।

1. Dashboard खोलें, फिर Playback पर जाएँ। सक्रिय सत्र (active session) में Transcoding लिखा होना चाहिए, और इसमें इसका कारण भी बताया जाना चाहिए। यदि इसमें Direct playing लिखा है, तो कुछ भी transcode नहीं हो रहा है और आप गलत फ़ाइल का परीक्षण कर रहे हैं।
2. Dashboard खोलें, फिर Logs पर जाएँ, और सबसे नई FFmpeg.Transcode लॉग फ़ाइल खोलें। एक हार्डवेयर transcode कमांड लाइन पर -hwaccel cuda और -hwaccel_output_format cuda दिखाता है, जिसमें encoder के रूप में h264_nvenc या hevc_nvenc होता है। वहाँ libx264 देखने का मतलब है कि आप सॉफ़्टवेयर में transcoding कर रहे हैं, चाहे सेटिंग्स पेज कुछ भी दावा करे।
3. प्लेबैक जारी रहने के दौरान होस्ट पर nvidia-smi चलाएँ। /usr/lib/jellyfin-ffmpeg/ffmpeg से एक प्रक्रिया दिखाई देनी चाहिए जिसमें GPU मेमोरी आवंटित हो, और nvidia-smi dmon -s u में enc और dec कॉलम शून्य (non-zero) होने चाहिए।

वह तीसरी जाँच कंटेनर के अंदर नहीं, बल्कि होस्ट पर चलाएँ। कंटेनर के अंदर nvidia-smi आमतौर पर एक खाली प्रक्रिया सूची दिखाता है क्योंकि यह अपने स्वयं के नेमस्पेस के बाहर की प्रक्रिया आईडी (process IDs) को नहीं देख सकता है, जबकि उपयोगिता संख्याएँ (utilisation numbers) अभी भी सही ढंग से पढ़ी जाती हैं। कंटेनर के अंदर खाली प्रक्रिया सूची कोई त्रुटि नहीं है।

जब यह बिना बताए सॉफ्टवेयर पर वापस आ जाता है

Jellyfin वीडियो चलाना जारी रखना पसंद करता है। जब हार्डवेयर पाथ उपलब्ध नहीं होता है, तो यह स्ट्रीम को फेल करने के बजाय सॉफ्टवेयर पर स्विच हो जाता है। इसलिए, सही संकेत एरर बैनर नहीं, बल्कि CPU लोड और FFmpeg लॉग है।

ट्रांसकोड लॉग में Cannot load libnvcuvid.so.1 का मतलब है कि डिकोडर लाइब्रेरी को कंटेनर में कभी माउंट ही नहीं किया गया था। NVIDIA_DRIVER_CAPABILITIES=all सेट करें और कंटेनर को फिर से बनाएं, क्योंकि एनवायरनमेंट में बदलाव के लिए इसे फिर से बनाने हेतु docker compose up -d की आवश्यकता होती है, और केवल रीस्टार्ट करने से पुरानी सेटिंग्स ही बनी रहती हैं।

h264_nvenc से No capable devices found का मतलब है कि FFmpeg एनकोडर लाइब्रेरी तक तो पहुँच गया लेकिन उसे कोई उपयोगी कार्ड नहीं मिला। docker compose exec jellyfin nvidia-smi को फिर से जाँचें, क्योंकि इसका आमतौर पर मतलब है कि डिवाइस रिजर्वेशन हटा दिया गया है या कंटेनर को पुरानी फाइल से फिर से बनाया गया है।

शांत GPU के साथ उच्च CPU उपयोग का मतलब है कि डिकोड साइड चुपचाप फेल हो रही है। उन कोडेक्स को अनटिक करें जिन्हें आपकी जनरेशन डिकोड नहीं कर सकती है, फिर उसी फाइल को दोबारा चलाएं और FFmpeg लॉग को फिर से पढ़ें कि क्या -hwaccel cuda दिखाई देता है।

यदि 4K HDR पर ट्रांसकोड शुरू होकर रुक जाता है जबकि 1080p ठीक चल रहा है, तो यह टोन-मैपिंग की सीमा है, न कि कोई टूटा हुआ इंस्टॉलेशन। nvidia-smi dmon -s u में sm कॉलम के साथ इसकी पुष्टि करें, फिर या तो क्लाइंट द्वारा अनुरोधित रिज़ॉल्यूशन को कम करें या 4K HDR फाइलों को उन क्लाइंट्स पर रखें जो उन्हें डायरेक्ट प्ले कर सकते हैं।

FAQ

NVENC इनेबल करने के बाद भी Jellyfin CPU का उपयोग क्यों कर रहा है?

Dashboard के अंतर्गत Logs में जाकर नवीनतम FFmpeg.Transcode लॉग देखें। यदि इसमें libx264 दिखाई देता है, तो इसका मतलब है कि किसी भी हार्डवेयर पाथ का उपयोग नहीं किया गया है। आमतौर पर इसका अर्थ है कि कंटेनर GPU को देख नहीं पा रहा है, इसलिए पुष्टि करने के लिए docker compose exec jellyfin nvidia-smi चलाएं। यदि इसमें h264_nvenc दिखाई देता है लेकिन CPU अभी भी व्यस्त है, तो डिकोड साइड सॉफ्टवेयर में चल रहा है। ऐसा तब होता है जब आपने ऐसा कोडेक चुना है जिसे आपका कार्ड डिकोड नहीं कर सकता, या जब 'Enable hardware encoding' को बंद रखा गया था, जिससे पाइपलाइन का केवल आधा हिस्सा ही GPU पर गया।

क्या मुझे अभी भी Docker Compose में runtime: nvidia लाइन की आवश्यकता है?

यदि आपके पास deploy.resources.reservations.devices ब्लॉक और एक आधुनिक Docker Compose है, तो इसकी आवश्यकता नहीं है। यह ब्लॉक डिवाइस-रिक्वेस्ट का आधुनिक तरीका है और वही काम करता है। runtime: nvidia, nvidia-docker2 युग का पुराना पाथ है, यह अभी भी काम करता है, और Jellyfin के स्वयं के प्रकाशित उदाहरण में दोनों रखे गए हैं। दोनों को रखने से कोई नुकसान नहीं है। केवल runtime: nvidia रखने का मतलब है कि आपको NVIDIA_VISIBLE_DEVICES=all को भी रखना होगा, क्योंकि उस पाथ में पढ़ने के लिए कोई डिवाइस रिक्वेस्ट नहीं होती और वह एनवायरनमेंट से डिवाइस लिस्ट लेता है।

एक NVIDIA GPU एक बार में कितने स्ट्रीम ट्रांसकोड कर सकता है?

अगस्त 2026 तक, NVIDIA का प्रकाशित मैट्रिक्स GeForce कार्ड्स के लिए बारह समवर्ती एनकोड सत्रों (concurrent encode sessions) की सीमा तय करता है, और डेटा सेंटर कार्ड्स को अप्रतिबंधित (unrestricted) बताया गया है। यह सीमा शायद ही कभी आपको रोकती है। HDR से SDR टोन मैपिंग NVENC के बजाय शेडर कोर पर चलती है, इसलिए सत्र काउंटर के मायने रखने से बहुत पहले ही कुछ 4K HDR स्ट्रीम शेडर्स को समाप्त कर देंगे। अपने मामले को nvidia-smi dmon -s u के साथ मापें और सत्र गणना के बजाय sm कॉलम पर ध्यान दें।

क्या मैं बिना GPU वाले VPS पर हार्डवेयर ट्रांसकोडिंग का उपयोग कर सकता हूँ?

नहीं। एनकोडिंग के लिए भौतिक NVENC ब्लॉक की आवश्यकता होती है, और एक मानक VPS पर lspci -nn | grep -Ei "3d|display|vga" केवल हाइपरवाइजर से एक वर्चुअल डिस्प्ले एडेप्टर दिखाता है। GPU-मुक्त प्लान पर वास्तविक समाधान ट्रांसकोड्स को हटाना है: क्लाइंट की क्वालिटी सेटिंग को Auto पर बढ़ाएं, ब्राउज़र के बजाय नेटिव क्लाइंट ऐप का उपयोग करें, और इमेज-आधारित सबटाइटल ट्रैक्स को टेक्स्ट में बदलें ताकि वे वीडियो को फिर से एनकोड करने के लिए मजबूर न करें।

1080p ठीक से ट्रांसकोड होने पर भी 4K HDR क्यों अटकता है?

ये दोनों वर्कलोड कार्ड के अलग-अलग हिस्सों का उपयोग करते हैं। 1080p SDR ट्रांसकोड केवल डिकोड और एनकोड है, जो दोनों फिक्स्ड-फंक्शन हार्डवेयर पर होते हैं। 4K HDR स्ट्रीम में टोन मैपिंग जुड़ जाती है, जो शेडर कोर पर चलने वाला एक CUDA फ़िल्टर है, साथ ही स्केल करने के लिए बहुत बड़ा फ्रेम होता है। nvidia-smi dmon -s u में उच्च sm के साथ कम enc और dec का दिखना इसकी पुष्टि करता है, क्योंकि इस पैटर्न का मतलब है कि फिक्स्ड-फंक्शन ब्लॉक खाली हैं और सामान्य-उद्देश्य वाले कोर ही सीमा हैं।