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. Docker ஒரு GPU-வை container-க்கு வழங்க ஏதுவாக NVIDIA Container Toolkit-ஐ நிறுவவும்.
3. docker-compose.yml-ல் Jellyfin service-க்காக GPU-வை ஒதுக்கி, container அதை அடையாளம் காண்கிறதா என்பதை உறுதிப்படுத்தவும்.
4. Jellyfin-ன் playback settings-ல் NVENC மற்றும் NVDEC-ஐ இயக்கி, உண்மையான playback-ல் அவை பயன்படுத்தப்படுகிறதா என்பதை உறுதிப்படுத்தவும்.

NVENC (NVIDIA encoder) மற்றும் NVDEC (NVIDIA decoder) ஆகியவை அந்த கார்டில் உள்ள நிலையான செயல்பாட்டுத் தொகுதிகள் (fixed-function blocks) ஆகும். இவை CUDA (compute unified device architecture) பணிகளைச் செய்யும் shader cores-லிருந்து தனித்தனி சிலிக்கான் பகுதிகளாகும். இந்தத் தனித்தன்மைதான் இதைச் செய்வதற்கு முக்கியக் காரணம்: மென்பொருள் மூலம் பல CPU cores-ஐப் பயன்படுத்தும் ஒரு stream, GPU-வில் ஒரு core-ன் சிறிய பகுதியையும், ஒரு பிரத்யேக hardware தொகுதியையும் மட்டுமே பயன்படுத்துகிறது.

Direct play என்பது transcode செய்வதை விட சிறந்தது, எனவே முதலில் அதைச் சரிபார்க்கவும்

இவற்றை உள்ளமைக்கும் முன், நீங்கள் எதற்காக transcode செய்கிறீர்கள் என்பதைக் கண்டறியவும்; அதை எளிதாக நீக்க முடியுமா என்று பார்க்கவும். ஒரு client-ஆல் கோப்பை அப்படியே இயக்க முடியாதபோது Jellyfin அதை transcode செய்கிறது. இதற்கான காரணங்கள் மிகச் சிலவே: video codec, audio codec, container format, image-based subtitles அல்லது client கோரிய bitrate வரம்பு.

Dashboard-ஐத் திறந்து, பின் Playback பகுதிக்குச் சென்று, ஏதேனும் ஒன்று இயங்கும்போது அந்த active session-ஐக் கவனிக்கவும். Direct playing என்று குறிக்கப்பட்ட session, கோப்பை மாற்றாமல் அப்படியே அனுப்புகிறது, இதற்கு CPU பயன்பாடு கிட்டத்தட்ட இல்லை. Transcoding என்று குறிக்கப்பட்ட session, Jellyfin ஏன் அந்த முடிவை எடுத்தது என்பதற்கான காரணத்தைக் காட்டும். அந்தக் காரணத்தை நீக்கிவிட்டால், GPU-வை இயக்க வேண்டிய அவசியமே இருக்காது.

இரண்டு மாற்றங்கள் பெரும்பாலான transcoding-களை நீக்கிவிடும். Client app-ன் தரத்தை (quality) Auto அல்லது அதிகபட்ச அளவிற்கு அமைக்கவும். ஏனெனில், 20 Mbps கோப்பை 4 Mbps-ல் கேட்கும் client, எந்த codec-ஆக இருந்தாலும் அதை மீண்டும் encode செய்ய கட்டாயப்படுத்தும். பிறகு, browser tab-க்கு பதிலாக native client app-ஐப் பயன்படுத்தவும். ஏனெனில், உங்களிடம் உள்ளவற்றிலேயே browser தான் மிகக் குறைந்த வசதி கொண்ட player. அதே TV-யில் உள்ள native app, அதே கோப்பை பெரும்பாலும் direct play செய்யும்.

Image-based subtitles இதற்கு விதிவிலக்கு, இதை எந்த client அமைப்பாலும் சரிசெய்ய முடியாது. Blu-ray rip-ல் உள்ள PGS subtitles மற்றும் DVD rip-ல் உள்ள VOBSUB ஆகியவை படங்களாக இருப்பதால், அவை வீடியோவின் மீது வரையப்பட வேண்டும். இதற்கு வீடியோ stream-ஐ முழுமையாக மீண்டும் encode செய்ய வேண்டும். SRT வடிவில் உள்ள text subtitles தனி track-ஆக client-க்கு அனுப்பப்படுவதால், அதற்கு எந்தச் செலவும் இல்லை. முடிந்தவரை subtitle track-களை text வடிவில் மாற்றுவது, ஒரு GPU-வை விட அதிகப் பலன் தரும். server-ன் பிற பகுதிகள் Jellyfin media server-ஐ VPS-ல் இயக்குவதற்கான வழிகாட்டி-யில் விவரிக்கப்பட்டுள்ளன.

பெரும்பாலான VPS திட்டங்களில் GPU இருப்பதில்லை

வழக்கமான VPS திட்டங்களில் GPU வழங்கப்படுவதில்லை. எதையும் திட்டமிடுவதற்கு முன்பாக, உங்கள் server-ல் இதைப் பரிசோதிக்கவும்.

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

வழக்கமான KVM VPS-ல், இது hypervisor-ன் virtual display adapter-ஐ மட்டுமே காட்டும், அல்லது பயனுள்ள தகவல் எதையும் காட்டாது. அந்தச் சாதனத்தால் வீடியோவை encode செய்ய முடியாது. ஒரு physical card-ஐ உங்கள் instance-க்கு provider நேரடியாக வழங்கினாலோ அல்லது அதன் ஒரு பகுதியை ஒதுக்கினாலோ மட்டுமே உண்மையான GPU கிடைக்கும்; அத்தகைய திட்டங்களுக்கு அதற்கேற்ப கட்டணம் வசூலிக்கப்படும். எந்த வகையான பணிகளுக்கு GPU VPS தேவைப்படும் என்ற பகுதி, யாருக்கு இது தேவை, யாருக்குத் தேவையில்லை என்பதை விளக்குகிறது.

GPU இல்லையெனில், direct play முறையையே பயன்படுத்தவும்; software transcoding-ஐ அரிதான சூழலில் மட்டும் பயன்படுத்தவும். ஒரு 1080p H.264 software transcode அதிக சுமையை ஏற்படுத்தினாலும், சில CPU cores மூலம் அதைச் சமாளிக்க முடியும். 4K HDR software transcode மற்றும் tone mapping ஆகியவற்றை ஒரு சிறிய VPS-ஆல் real-time-ல் செய்ய முடியாது. இதனால் CPU பயன்பாடு 100 சதவீதத்தை எட்டி, stream தடைபடும்.

Host-ல் NVIDIA driver-ஐ நிறுவுதல்

Jellyfin 10.11, Linux-ல் குறைந்தபட்சம் 520.56.06 NVIDIA driver இருக்க வேண்டும் என்று குறிப்பிடுகிறது. Ubuntu-வில் உங்களுக்காகப் பொருத்தமான தொகுப்பைத் தேர்ந்தெடுக்கும் ஒரு helper வசதி உள்ளது.

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

--gpgpu என்பது driver-ன் headless server வகையைத் தேர்ந்தெடுக்கிறது. இது ஒரு media server-க்குத் தேவையானது, ஏனெனில் அந்த machine-ல் desktop சூழல் இருக்காது. list கட்டளை உங்களுக்குக் கிடைக்கும் கிளைகளைக் (branches) காட்டும், நீங்கள் ஒரு கிளையை அதன் பெயரைக் கொண்டு pin செய்யலாம், உதாரணமாக sudo ubuntu-drivers install --gpgpu nvidia:570-server. இங்கே கொடுக்கப்பட்டுள்ள பெயரைப் பயன்படுத்தாமல், list கட்டளையில் காட்டப்பட்ட கிளையைப் பயன்படுத்தவும்.

Server வகை எப்போதும் nvidia-smi-ஐத் தானாக நிறுவாது. நீங்கள் தேர்ந்தெடுத்த கிளைக்குரிய utils தொகுப்பை நிறுவவும், உதாரணமாக sudo apt install nvidia-utils-570-server. அதன் பிறகு driver-ஐச் சரிபார்க்கவும்.

nvidia-smi

சரியான முடிவில், தலைப்பில் driver பதிப்பு மற்றும் CUDA பதிப்புடன் கூடிய ஒரு அட்டவணை வரும், அதில் உங்கள் card-ன் பெயர் பட்டியலிடப்பட்டிருக்கும், மேலும் process பட்டியல் காலியாக இருக்கும். இதில் பொதுவாக இரண்டு பிழைகள் ஏற்படலாம். nvidia-smi: command not found என்பது driver இல்லை என்று அர்த்தமல்ல, utils தொகுப்பு விடுபட்டுள்ளது என்று அர்த்தம். 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-ஐ நிறுவுதல்

GPU-ஐ host பயன்படுத்த NVIDIA driver அனுமதிக்கிறது. இருப்பினும், container-ல் device nodes அல்லது driver libraries இல்லாததால், Docker-ஆல் GPU-ஐ container-க்குள் கொண்டு செல்ல முடியாது. container தொடங்கும் போது இவை இரண்டையும் உள்ளே செலுத்தும் பணியை NVIDIA Container Toolkit செய்கிறது. 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

Docker-க்கு இந்த runtime இருப்பதை தெரிவிக்க வேண்டியுள்ளதால், package-ஐ நிறுவுவது மட்டும் போதாது.

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

nvidia-ctk runtime configure, /etc/docker/daemon.json கோப்பில் ஒரு nvidia runtime entry-ஐ எழுதும். பலர் இந்த restart செய்வதை மறந்துவிடுகிறார்கள்; இதைத் தவிர்ப்பதுதான் இந்த அமைப்பில் ஏற்படும் மிக பொதுவான பிழைக்குக் காரணமாகிறது. Jellyfin-ஐ அமைக்கும் முன் இந்த இணைப்புகளைச் சோதிக்கவும்.

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

இது host-ல் காட்டப்பட்ட அதே அட்டவணையை அச்சிட வேண்டும். ஒருவேளை, gpu capabilities கொண்ட device driver-ஐ தேர்ந்தெடுக்க முடியவில்லை என்ற பிழை ஏற்பட்டால், Docker daemon-க்கு nvidia runtime பற்றி தெரியவில்லை என்று அர்த்தம். எனவே, configure கட்டளையை மீண்டும் இயக்கி, 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 அட்டவணையை வெளியிட்டால், GPU சரியாக pass-through செய்யப்பட்டுள்ளது என்று அர்த்தம். மீதமுள்ள அனைத்து சிக்கல்களும் Jellyfin அமைப்புகள் சார்ந்தவை.

அந்தக் கோப்பில் உள்ள நான்கு வரிகளுக்கு விளக்கம் தேவை. capabilities: [gpu] என்பது Compose-க்கு அவசியமானது; இதைத் தவிர்த்தால், GPU இல்லாமல் தொடங்குவதற்குப் பதிலாக, Compose அந்தச் சேவையைத் தொடங்க மறுத்துவிடும். NVIDIA_DRIVER_CAPABILITIES=all முக்கியமானது, ஏனெனில் video capability கோரப்படும்போது மட்டுமே toolkit வீடியோ நூலகங்களை (libraries) container-க்குள் mount செய்கிறது. அதிகாரப்பூர்வ image-க்கு இந்த variable தேவை என்று Jellyfin ஆவணங்கள் குறிப்பிடுகின்றன. இது இல்லையென்றால் 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-ல் Jellyfin எந்தக் கோப்புகளைப் படிக்க முடியும் என்பதை இது தீர்மானிக்கிறது. இதில் ஏதேனும் முரண்பாடு இருந்தால், permissions பிழைக்கு பதிலாக library காலியாகக் காட்டும். PUID மற்றும் PGID எவ்வாறு container பயனர் ஒருவரை வட்டில் உள்ள கோப்புகளுடன் இணைக்கிறது என்பது அந்த எண்களை விளக்குகிறது. நீங்கள் Sonarr மற்றும் Radarr stack-ஐ Docker Compose-ல் இதற்கு அருகில் இயக்கும்போது ஏற்கனவே அமைத்த அதே எண்கள்தான் இவையும்.

ஏன் பெரும்பாலான பயிற்சிகள் இன்னும் runtime: nvidia என்று குறிப்பிடுகின்றன

நீங்கள் காணும் பெரும்பாலான வழிகாட்டிகளில் பழைய வடிவம் இடம்பெற்றுள்ளது, அது தவறானதல்ல. அது ஒரு வரலாறு. அசல் nvidia-docker2 தொகுப்பு 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-ஐக் குறிக்கும் என்று பெரும்பாலானோர் பழகியிருந்ததால், இந்த key-ஐ அவர்கள் கவனிக்கவில்லை.

இதன் விளைவாக, இன்று இரண்டு வடிவங்களும் வேலை செய்கின்றன, மேலும் Jellyfin-ன் அதிகாரப்பூர்வ உதாரணத்தில் இவை இரண்டும் ஒரே நேரத்தில் உள்ளன. runtime: nvidia-ஐ வைத்திருப்பதால் எந்தப் பாதிப்பும் இல்லை, மேலும் இது பழைய Compose பதிப்புகளிலும் கோப்பு வேலை செய்ய உதவுகிறது. நீங்கள் runtime: nvidia-ஐ மட்டும் வைத்துக்கொண்டு deploy தொகுப்பை நீக்கினால், நீங்கள் NVIDIA_VISIBLE_DEVICES=all-ஐ வைத்திருக்க வேண்டும். ஏனெனில், அந்தப் பழைய வழிமுறை எந்தெந்த சாதனங்களை உள்ளீடு செய்ய வேண்டும் என்பதைத் தீர்மானிக்க environment variable-ஐ மட்டுமே வாசிக்கும், அதற்குப் பதிலாக வாசிப்பதற்கு வேறு device request எதுவும் இருக்காது.

Jellyfin-ல் NVIDIA hardware transcoding-ஐ இயக்குதல்

இதுவரை Jellyfin-க்கு GPU-ஐப் பயன்படுத்த எந்தக் கட்டளையும் வழங்கப்படவில்லை. Dashboard பகுதிக்குச் சென்று, Playback என்பதைத் தேர்ந்தெடுத்து, பின் Transcoding பகுதிக்குச் செல்லவும். Hardware acceleration என்பதை Nvidia NVENC என மாற்றவும். Enable hardware encoding என்பதைத் தேர்ந்தெடுக்கவும்; இல்லையெனில், Jellyfin GPU-வில் decode செய்துவிட்டு CPU-வில் encode செய்யும். இது குழப்பமான ஒரு நிலையாகும், இதில் GPU செயல்படுவது போலத் தெரிந்தாலும் CPU அதிக சுமையுடன் இருக்கும்.

Enable enhanced NVDEC decoder என்பது தற்போதைய NVDEC பாதைக்கும் பழைய CUVID பாதைக்கும் இடையே மாற உதவுகிறது. இதை அப்படியே வைத்திருக்கவும். Dolby Vision-ஐக் கையாள NVDEC-ஐப் பயன்படுத்த இது அவசியமாகும்.

Enable hardware decoding for என்பதன் கீழ், உங்கள் கார்டு உண்மையில் எவற்றை decode செய்யுமோ அவற்றை மட்டும் தேர்ந்தெடுக்கவும். இதுவே பலரும் தவறு செய்யும் இடமாகும். AV1 decoder இல்லாத கார்டில் AV1-ஐத் தேர்ந்தெடுத்தால் பிழைச் செய்தி வராது. Jellyfin வன்பொருள் மூலம் decode செய்ய முயன்று, அது கிடைக்காதபோது மென்பொருள் (software) மூலம் decode செய்யத் தொடங்கும். இதனால் CPU பயன்பாடு அதிகமாகவும், GPU பயன்பாடு குறைவாகவும் இருக்கும்; இது passthrough சரியாக வேலை செய்யாதது போன்ற தோற்றத்தைத் தரும்.

இந்த முழுப் பக்கத்திற்கும் பொருந்தும் மற்றொரு கட்டுப்பாடு: hardware acceleration என்பது தொகுக்கப்பட்ட jellyfin-ffmpeg build-உடன் மட்டுமே வேலை செய்யும். நீங்கள் FFmpeg பாதையை system FFmpeg-க்கு மாற்றியிருந்தால், acceleration பகுதி அளவுக்கோ அல்லது முழுமையாகவோ கிடைக்காது.

உங்கள் GPU தலைமுறை எவற்றை decode மற்றும் encode செய்ய முடியும்

NVENC மற்றும் NVDEC-க்காக Jellyfin ஆவணப்படுத்தியுள்ள எல்லைகள் இவை. Decode மற்றும் encode ஆகிய இரண்டும் தனித்தனி திறன்கள்; ஒரு card-ல் ஒன்று இருந்து மற்றொன்று இல்லாமல் இருக்கலாம்.

• H.264 8-bit: NVENC மற்றும் NVDEC இரண்டையும் கொண்ட ஒவ்வொரு NVIDIA GPU-வும் இதை decode மற்றும் encode செய்யும்.
• HEVC 8-bit: Maxwell இரண்டாம் தலைமுறை (GM206) மற்றும் அதற்குப் பிந்தையவற்றில் decode மற்றும் encode செய்ய முடியும்.
• HEVC 10-bit: Maxwell இரண்டாம் தலைமுறை மற்றும் அதற்குப் பிந்தையவற்றில் decode செய்ய முடியும், ஆனால் Pascal மற்றும் அதற்குப் பிந்தையவற்றில் மட்டுமே encode செய்ய முடியும்.
• 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 செய்கிறது. அது தொடர்ந்து இயங்கும், மேலும் பெரும்பாலான client-களுக்கு அதுவே சரியான தேர்வாகும். உங்கள் card எதுவாக இருந்தாலும் 2026-ல் AV1 encode என்பது அரிதாகவே தேவைப்படும், ஏனெனில் client-side AV1 decode ஆதரவு இன்னும் குறைவாகவே உள்ளது, மேலும் ஏற்கனவே சிரமப்படும் ஒரு client-ஐ சென்றடையவே transcode செய்யப்படுகிறது.

GPU ஏன் அமைதியாக tone mapping மூலம் அதிக சுமையை எதிர்கொள்கிறது

HDR (high dynamic range)-லிருந்து SDR (standard dynamic range)-க்கு மாற்றும் tone mapping அமைப்பானது உங்கள் GPU-வின் செயல்திறனைப் பெரிதும் பாதிக்கிறது. இதற்கான காரணம் அதன் கட்டமைப்பு சார்ந்தது. Decode செயல்முறை NVDEC-ல் இயங்குகிறது. Encode செயல்முறை NVENC-ல் இயங்குகிறது. ஆனால், tone mapping இவை இரண்டிலும் இயங்குவதில்லை: இது shader cores-ல் இயங்கும் ஒரு CUDA filter ஆகும். இது compute பணிகளைச் செய்யும் GPU-வின் பொதுவான பகுதியாகும். எனவே, tone mapping தேவைப்படும் ஒரு 4K HDR stream, decoder மற்றும் encoder-ஐப் பயன்படுத்துவதுடன், கூடுதல் சுமையாக shader-களையும் பயன்படுத்துகிறது.

HEVC 10-bit decode செய்யக்கூடிய அனைத்து NVIDIA GPU-களிலும் CUDA tone mapping வசதி இருப்பதாக Jellyfin ஆவணப்படுத்துகிறது. இதன் பொருள், 4K தரத்தில் இதைத் தாங்க முடியாத கார்டுகளிலும் இந்த checkbox தோன்றும் மற்றும் செயல்படும். இதன் அறிகுறி என்னவென்றால், ஒரு stream தொடங்கும், ஆனால் buffer ஆகிக்கொண்டே இருக்கும், அதே சமயம் nvidia-smi encoder-ன் பயன்பாடு மிகக் குறைவாக இருப்பதைக் காட்டும்.

இதனால்தான் shader-ன் சுமையை தனித்தனியாகக் கண்காணிப்பது அவசியமானது.

nvidia-smi dmon -s u

இது ஒவ்வொரு வினாடிக்கும் ஒரு வரியை அச்சிடும், இதில் sm, enc மற்றும் dec ஆகியவற்றுக்குத் தனித்தனி நெடுவரிசைகள் இருக்கும். enc மற்றும் dec பயன்பாடு குறைவாக இருந்து, sm எண் அதிகமாக இருந்தால், fixed-function தொகுதிகள் சும்மா இருக்கின்றன என்றும், shader-களே தடையாக (bottleneck) இருக்கின்றன என்றும் பொருள். எனவே, tone mapping, scaling அல்லது subtitle burn-in ஆகியவையே உங்கள் செயல்திறனைக் குறைக்கின்றன. CUDA பாதை Dolby Vision profile 5-ஐ zero copy மூலம் கையாள்கிறது. இது முக்கியமானது, ஏனெனில் zero copy இல்லையென்றால், ஒவ்வொரு filter படிநிலையின் போதும் frames கணினியின் நினைவகத்திற்குச் சென்று மீண்டும் வரும். இந்தச் சுழற்சி ஒவ்வொரு frame-க்கும் அதிக bandwidth-ஐச் செலவழிக்கும்.

நுகர்வோர் NVENC session வரம்பு எதை உண்மையில் கட்டுப்படுத்துகிறது

[
  {
    "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 ஒரே நேரத்தில் இயங்கும் encode sessions-க்கு மட்டுமே கட்டுப்படுத்தப்பட்டுள்ளது. இந்த வரம்பு சிலிக்கானில் (silicon) இல்லாமல் driver-ல் உள்ளது, மேலும் NVIDIA பல ஆண்டுகளாக இதை பலமுறை உயர்த்தியுள்ளது, எனவே பழைய forum விவாதங்களைப் பார்க்காமல் தற்போதைய தரவுத்தளத்தைப் பார்க்கவும். கார்டுக்கு கார்டு மாறுபடும் உண்மையான அம்சம் engine எண்ணிக்கை மட்டுமே: GeForce RTX 5090 ஆனது 3 NVENC engines-ஐக் கொண்டுள்ளது, அதே சமயம் GeForce RTX 4060 ஆனது 1 engines-ஐக் கொண்டுள்ளது. அதிக engines என்பது அதிக parallel encode throughput-ஐக் குறிக்குமே தவிர, அதிக session வரம்பைக் குறிக்காது.

இந்த வரம்பு encode sessions-ஐ மட்டுமே கணக்கிடுகிறது, எனவே இது transcoding streams-க்கு மட்டுமே பொருந்தும். Direct play மற்றும் remuxing ஆகியவை ஒருபோதும் encode session-ஐத் திறப்பதில்லை. L4 போன்ற data center கார்டுகள் அதே தரவுத்தளத்தில் கட்டுப்பாடற்றவை (unrestricted) என்று பட்டியலிடப்பட்டுள்ளன, மேலும் GPU VPS திட்டங்களில் பொதுவாக இத்தகைய data center கார்டுகளே வழங்கப்படுகின்றன, எனவே இந்த வரம்பு பெரும்பாலும் home-server பயனர்களுக்கு மட்டுமே ஒரு கவலையாக இருக்கும்.

நீங்கள் இந்த வரம்பை எட்டும்போது, transcode தோல்வியடையும் மற்றும் FFmpeg log-ல் OpenEncodeSessionEx failed: out of memory (10) பிழை தோன்றும். அந்தச் செய்தி memory பற்றாக்குறையைக் குறிப்பிட்டாலும், session-limit மறுப்பும் அதே குறியீட்டையே காட்டும், எனவே VRAM கசிவைத் தேடுவதற்கு முன் உங்கள் concurrent stream எண்ணிக்கையைச் சரிபார்க்கவும். நடைமுறையில், பெரும்பாலான பயனர்கள் பன்னிரண்டு sessions-ஐ எட்டுவதற்கு முன்பே tone-mapping வரம்பையோ அல்லது தங்கள் upload bandwidth வரம்பையோ அடைந்துவிடுவார்கள்.

GPU transcoding செய்கிறதா என்பதை உறுதிப்படுத்துதல், அமைப்புகளை மட்டும் நம்ப வேண்டாம்

சேமிக்கப்பட்ட அமைப்பு என்பது ஆதாரமல்ல. Transcoding-ஐ கட்டாயப்படுத்தும் ஒரு கோப்பை இயக்கி, பின்வரும் மூன்று சோதனைகளைச் செய்யவும்.

1. Dashboard-ஐத் திறந்து, பின் Playback-க்குச் செல்லவும். தற்போதைய session-ல் Transcoding என்று இருக்க வேண்டும், அதற்கான காரணமும் குறிப்பிடப்பட்டிருக்க வேண்டும். அது Direct playing என்று காட்டினால், எந்த transcoding-ம் நடக்கவில்லை என்று பொருள்; நீங்கள் தவறான கோப்பைச் சோதிக்கிறீர்கள்.
2. Dashboard-ஐத் திறந்து, Logs-க்குச் சென்று, புதிய FFmpeg.Transcode log-ஐத் திறக்கவும். Hardware transcode நடந்தால், command line-ல் -hwaccel cuda மற்றும் -hwaccel_output_format cuda இருக்கும், encoder-ஆக h264_nvenc அல்லது hevc_nvenc குறிப்பிடப்பட்டிருக்கும். அங்கு libx264 என்று இருந்தால், அமைப்புகள் பக்கத்தில் என்ன இருந்தாலும், அது software மூலம் transcoding செய்கிறது என்று பொருள்.
3. கோப்பு இயங்கிக்கொண்டிருக்கும்போது, host-ல் nvidia-smi கட்டளையை இயக்கவும். /usr/lib/jellyfin-ffmpeg/ffmpeg-லிருந்து ஒரு process தோன்றி, GPU memory ஒதுக்கப்பட்டிருக்க வேண்டும். மேலும், nvidia-smi dmon -s u-ல் enc மற்றும் dec நெடுவரிசைகள் பூஜ்ஜியமற்ற மதிப்புகளைக் காட்ட வேண்டும்.

இந்த மூன்றாவது சோதனையை container-க்குள் செய்யாமல், host-ல் செய்யவும். Container-க்குள் nvidia-smi கட்டளையை இயக்கினால், அதன் சொந்த namespace-க்கு வெளியே உள்ள process ID-களைப் பார்க்க முடியாது என்பதால், அது பெரும்பாலும் காலியான process பட்டியலையே காட்டும். அதே சமயம், பயன்பாட்டு எண்கள் (utilisation numbers) சரியாகவே இருக்கும். Container-க்குள் process பட்டியல் காலியாக இருப்பது பிழையல்ல.

மென்பொருள் முறைக்குத் தானாக மாறும்போது

Jellyfin தொடர்ந்து இயங்குவதையே விரும்புகிறது. வன்பொருள் (hardware) பாதை கிடைக்காதபோது, அது ஸ்ட்ரீமைத் துண்டிப்பதற்குப் பதிலாக மென்பொருள் (software) முறைக்கு மாறிவிடும். எனவே, பிழைச் செய்தியை விட CPU பயன்பாடு மற்றும் FFmpeg பதிவேடுகளே (logs) உண்மையான நிலையை உணர்த்தும்.

Cannot load libnvcuvid.so.1 என்பது transcode பதிவேட்டில் இருந்தால், decoder library கொள்கலனில் (container) இணைக்கப்படவில்லை என்று பொருள். NVIDIA_DRIVER_CAPABILITIES=all-ஐ அமைத்து, கொள்கலனை மீண்டும் உருவாக்கவும். ஏனெனில், சூழல் மாற்றங்களுக்கு (environment change) docker compose up -d தேவைப்படுகிறது; சாதாரண restart பழைய அமைப்புகளையே வைத்திருக்கும்.

h264_nvenc-லிருந்து வரும் No capable devices found, FFmpeg என்கோடர் லைப்ரரியை அடைந்தாலும், பயன்படுத்தக்கூடிய கார்டு (card) எதையும் கண்டறியவில்லை என்பதைக் குறிக்கிறது. docker compose exec jellyfin nvidia-smi-ஐ மீண்டும் சரிபார்க்கவும்; ஏனெனில், சாதனம் ஒதுக்கீடு (device reservation) நீக்கப்பட்டாலோ அல்லது பழைய கோப்பிலிருந்து கொள்கலன் மீண்டும் உருவாக்கப்பட்டாலோ இது நிகழும்.

GPU அமைதியாக இருந்து CPU பயன்பாடு அதிகமாக இருந்தால், decode செய்யும் பகுதியில் அமைதியான தோல்வி ஏற்படுகிறது என்று பொருள். உங்கள் தலைமுறைக்கு (generation) பொருந்தாத கோடெக்குகளை (codecs) நீக்கிவிட்டு, அதே கோப்பை மீண்டும் இயக்கவும். அப்போது -hwaccel cuda தோன்றுகிறதா என்று FFmpeg பதிவேட்டில் பார்க்கவும்.

1080p சரியாக இயங்கி, 4K HDR மட்டும் தொடங்கி நின்றுவிட்டால், அது நிறுவல் கோளாறு அல்ல, tone-mapping வரம்பாகும். nvidia-smi dmon -s u-ல் உள்ள sm நெடுவரிசையைப் பார்த்து இதை உறுதிப்படுத்தவும். பின்னர், client கோரும் resolution-ஐக் குறைக்கவும் அல்லது 4K HDR கோப்புகளை நேரடியாக இயக்கக்கூடிய (direct play) client-களில் மட்டும் பயன்படுத்தவும்.

FAQ

NVENC-ஐ இயக்கிய பிறகும் Jellyfin ஏன் CPU-ஐப் பயன்படுத்துகிறது?

Dashboard-ல் உள்ள Logs பகுதிக்குச் சென்று, சமீபத்திய FFmpeg.Transcode பதிவைப் பார்க்கவும். அதில் libx264 என்று இருந்தால், எந்தவொரு hardware பாதையும் பயன்படுத்தப்படவில்லை என்று பொருள். பொதுவாக, container-ஆல் GPU-ஐக் கண்டறிய முடியவில்லை என்று அர்த்தம்; இதை உறுதிப்படுத்த docker compose exec jellyfin nvidia-smi கட்டளையை இயக்கவும். ஒருவேளை h264_nvenc என்று காட்டியும் CPU அதிகப்படியாகப் பயன்படுத்தப்பட்டால், decoding மென்பொருள் (software) மூலமாகவே நடக்கிறது என்று பொருள். உங்கள் GPU-ஆல் ஆதரிக்கப்படாத codec-ஐத் தேர்ந்தெடுத்திருந்தாலோ அல்லது Enable hardware encoding விருப்பத்தை முடக்கி வைத்திருந்தாலோ, pipeline-ன் பாதி மட்டுமே GPU-க்குச் செல்லும்.

Docker Compose-ல் இன்னும் runtime: nvidia வரி தேவையா?

உங்களிடம் deploy.resources.reservations.devices தொகுதி மற்றும் தற்போதைய Docker Compose இருந்தால், அது தேவையில்லை. அந்தத் தொகுதி நவீன device-request வடிவமாகும், அதுவே அதே பணியைச் செய்யும். runtime: nvidia என்பது nvidia-docker2 காலத்து பழைய முறையாகும்; அது இப்போதும் வேலை செய்யும், Jellyfin-ன் அதிகாரப்பூர்வ உதாரணங்களில் இரண்டுமே கொடுக்கப்பட்டுள்ளன. இரண்டையும் வைத்திருப்பதில் பாதிப்பில்லை. runtime: nvidia-ஐ மட்டும் வைத்திருந்தால், நீங்கள் NVIDIA_VISIBLE_DEVICES=all-ஐயும் வைத்திருக்க வேண்டும், ஏனெனில் அந்தப் பாதையில் device-ஐக் கண்டறியும் கோரிக்கை இல்லை, அது environment-லிருந்து device பட்டியலை எடுத்துக்கொள்ளும்.

ஒரு NVIDIA GPU ஒரே நேரத்தில் எத்தனை streams-ஐ transcode செய்ய முடியும்?

ஆகஸ்ட் 2026 நிலவரப்படி, NVIDIA-வின் அதிகாரப்பூர்வ தரவுத்தளம் GeForce கார்டுகளுக்கு ஒரே நேரத்தில் பன்னிரண்டு encode sessions-க்கு மேல் அனுமதிப்பதில்லை, ஆனால் data center கார்டுகளுக்கு வரம்பு இல்லை. இந்த வரம்பு பெரும்பாலும் ஒரு தடையாக இருப்பதில்லை. HDR-லிருந்து SDR-க்கு tone mapping செய்வது NVENC-ல் அல்லாமல் shader cores-ல் நடக்கிறது. எனவே, session எண்ணிக்கையை எட்டுவதற்கு முன்பே, சில 4K HDR streams-களே shader-களை முழுமையாகப் பயன்படுத்திவிடும். உங்கள் சூழலை nvidia-smi dmon -s u மூலம் அளவிடவும்; session எண்ணிக்கையை விட sm column-ஐக் கவனிக்கவும்.

GPU இல்லாத VPS-ல் hardware transcoding-ஐப் பயன்படுத்த முடியுமா?

முடியாது. Encoding-க்கு இயற்பியல் ரீதியான NVENC தொகுதி தேவை. சாதாரண VPS-ல் lspci -nn | grep -Ei "3d|display|vga" கட்டளையை இயக்கினால், hypervisor வழங்கும் virtual display adapter மட்டுமே தெரியும். GPU இல்லாத திட்டத்தில், transcoding-ஐத் தவிர்ப்பதே சிறந்த வழி: client-ன் தர அமைப்பை (quality setting) Auto-வில் வைக்கவும், browser-க்குப் பதிலாக native client app-ஐப் பயன்படுத்தவும், image-அடிப்படையிலான subtitle tracks-ஐ text வடிவில் மாற்றவும்; இது வீடியோவை மீண்டும் encode செய்வதைத் தவிர்க்கும்.

1080p நன்றாக transcode ஆகும் நிலையில், 4K HDR ஏன் தடைபடுகிறது (stutter)?

இந்த இரண்டு பணிகளும் கார்டின் வெவ்வேறு பகுதிகளைப் பயன்படுத்துகின்றன. 1080p SDR transcode என்பது decode மற்றும் encode மட்டுமே; இவை இரண்டும் fixed-function hardware-ல் நடக்கும். 4K HDR stream-ல் tone mapping சேர்க்கப்படுகிறது, இது shader cores-ல் இயங்கும் ஒரு CUDA filter ஆகும்; மேலும், பெரிய அளவிலான frame-களை scale செய்யவும் வேண்டும். nvidia-smi dmon -s u-ல் enc மற்றும் dec குறைவாகவும், sm அதிகமாகவும் இருந்தால், fixed-function தொகுதிகள் சும்மா இருப்பதையும், general-purpose cores-ன் திறன் வரம்பை எட்டியிருப்பதையும் அது உறுதிப்படுத்துகிறது.