젤리핀 트랜스코딩 하드웨어 가속 확인 방법, 켰는데 버벅일 때 로그에서 볼 곳

젤리핀 트랜스코딩 하드웨어 가속 확인은 설정 화면이 아니라 FFmpeg 로그의 인코더 이름에서 끝납니다. 로그에 libx264가 찍혀 있으면 설정에 뭐라고 적혀 있든 그 영상은 CPU로 돌고 있는 겁니다.

가속을 켜 놨는데도 끊기는 서버는 원인이 셋 중 하나로 갈립니다. 가속이 통째로 빠졌거나, 디코딩만 GPU가 하고 있거나, 가속은 됐는데 병목이 다른 곳에 있는 경우입니다. 이 글은 설정 방법을 반복하지 않고, 이 셋을 로그 한 번으로 가려내는 기준만 다룹니다.

🔥 젤리핀 트랜스코딩 하드웨어 가속 확인 핵심 요약
• 대시보드 > 로그의 FFmpeg.Transcode 파일에서 인코더가 libx264·libx265면 CPU, h264_qsv·h264_vaapi·h264_nvenc 계열이면 GPU입니다.
• 디코딩(-hwaccel 유무)과 인코딩(인코더 이름)은 따로 판정됩니다. 한쪽만 GPU인 '반쪽 가속'이 있습니다.
• 둘 다 GPU인데도 끊긴다면 ffmpeg 진행 줄의 speed 값이 1.0x 아래인지부터 보세요. 그때부터는 GPU 밖의 병목입니다.

확인 기준: 2026년 10월, Jellyfin 공식 문서(Intel·NVIDIA 하드웨어 가속 가이드)와 10.11 계열 서버. 메뉴 이름은 버전과 언어 설정에 따라 조금 다를 수 있습니다.

먼저 본인이 어느 쪽인지부터 갈라 보세요.
인코더가 libx264이고 -hwaccel도 없다면 가속이 통째로 빠진 경우라 네 번째 섹션으로 가시면 됩니다.
-hwaccel은 있는데 인코더만 libx264라면 디코딩만 GPU가 하는 반쪽 상태입니다.
인코더까지 하드웨어인데 끊긴다면 다섯 번째 섹션의 speed 값과 병목 후보를 보시면 됩니다.

젤리핀 트랜스코딩 하드웨어 가속 확인이 설정 화면만으로 안 되는 이유

설정 화면의 가속 옵션은 "이 방식으로 시도해 달라"는 지시일 뿐, 실제로 쓰였다는 기록이 아닙니다. 젤리핀은 재생을 시작할 때마다 그 영상의 코덱·비트레이트·HDR 여부·자막 형식에 맞춰 FFmpeg 명령을 새로 만듭니다.

그래서 같은 서버, 같은 설정인데 A 영상은 GPU로, B 영상은 CPU로 갈리는 일이 생깁니다. 장치가 아예 안 잡히면 대체로 재생이 에러로 끝나서 오히려 눈에 띄고, 골치 아픈 쪽은 재생은 되는데 특정 영상만 CPU로 돌아가는 경우입니다.

증거가 남는 곳은 두 군데입니다. 대시보드 > 로그에서 FFmpeg.Transcode로 시작하는 파일이 그 재생의 실제 명령과 진행 기록입니다. 대시보드의 활성 기기 화면에서 재생 중인 항목의 정보(i) 버튼을 누르면 트랜스코딩이 걸린 이유가 나옵니다.

1. 버벅이는 영상을 트랜스코딩이 걸리는 조건 그대로 재생합니다.
2. 재생 중에 대시보드 > 로그로 들어갑니다.
3. FFmpeg.Transcode-날짜시각 파일 중 가장 최신 것을 엽니다.
4. 맨 위 명령줄과 'Stream mapping' 줄을 봅니다.

파일 위치는 보통 패키지 설치라면 /var/log/jellyfin, Docker라면 설정 볼륨 안의 log 폴더입니다. 대시보드에서 바로 열리니 굳이 찾아 들어갈 일은 드뭅니다.

⚠️ 설정을 바꿨다면 새 재생부터 확인하세요
재생 중이던 세션은 바꾸기 전 명령으로 계속 돌아갑니다. 이전 로그 파일을 읽고 판단하면 바꾸기 전 결과를 보게 됩니다.

로그에서 읽을 곳은 세 군데, -hwaccel·인코더 이름·필터 체인

입력(-i) 앞의 -hwaccel은 디코딩, 출력 쪽 -codec:v:0 뒤의 이름은 인코딩, -vf 안의 필터 이름은 크기 조절과 톤매핑이 어디서 도는지를 알려 줍니다. 세 곳이 각각 따로 판정됩니다.

(핵심 옵션만 발췌·단순화한 예시)
ffmpeg ... -hwaccel qsv -hwaccel_output_format qsv ... -i file:"/media/movie.mkv" ... -codec:v:0 h264_qsv ...

Stream mapping:
  Stream #0:0 -> #0:0 (hevc (native) -> h264 (h264_qsv))

• -hwaccel vaapi · qsv · cuda가 -i 앞에 있으면 디코딩을 GPU에 맡기려 한 겁니다.
• h264_qsv · h264_vaapi · h264_nvenc · hevc_ 계열이 인코더 자리에 있으면 인코딩이 GPU입니다. libx264 · libx265면 CPU입니다.
• scale_qsv · scale_vaapi · scale_cuda · tonemap_opencl 같은 이름이 -vf에 있으면 크기 조절이나 톤매핑도 GPU에서 도는 겁니다.
• hwdownload가 보이면 GPU 프레임을 CPU 메모리로 내리는 구간이 있다는 신호입니다. 자막 굽기나 톤매핑 필터가 걸린 영상에서 흔히 보이는 모양입니다.

한 가지 함정이 있습니다. Stream mapping 줄의 (native)는 디코더 이름일 뿐이라, 이것만 보고 소프트웨어 디코딩이라고 단정하면 안 됩니다. 디코딩이 GPU인지는 -hwaccel을 따로 봐야 합니다. 반대로 괄호 안 인코더 이름은 그대로 믿어도 됩니다.

이 세 곳을 조합하면 판정은 셋뿐입니다. 솔직히 이 줄만 읽을 줄 알면 설정 화면은 거의 볼 필요가 없습니다.

로그가 맞는지 호스트에서 한 번 더, 하드웨어별 확인 도구

로그에서 GPU 인코더로 보였다면 호스트 쪽 도구로 실제 부하가 걸리는지 교차 확인하세요. 환경마다 쓰는 도구가 다릅니다.

환경	확인 명령	가속 중이면 보이는 것	놓치기 쉬운 점
Intel 내장 그래픽(QSV·VAAPI)	sudo intel_gpu_top	재생 중 Video·Render 엔진 사용률 상승	컨테이너 안이 아니라 호스트 터미널에서 실행
NVIDIA, 리눅스	nvidia-smi, nvidia-smi dmon -s u	프로세스 목록의 jellyfin-ffmpeg, VRAM 점유, dmon의 enc·dec 열	컨테이너 환경에선 프로세스 목록이 비어 보일 수 있어 dmon 사용률로 교차
NVIDIA, 윈도우	작업 관리자 > 성능 > GPU	Video Decode·Video Encode 엔진 점유	Cuda 항목이 아니라 Video 엔진 항목을 볼 것
Docker 안(Intel·AMD VAAPI)	docker exec -it 컨테이너명 /usr/lib/jellyfin-ffmpeg/vainfo --display drm --device /dev/dri/renderD128	H264·HEVC 프로파일 목록, VAEntrypointVLD(디코드)·EncSlice(인코드)	여기서 에러면 장치가 컨테이너에 안 보이는 겁니다
모든 환경	top 또는 htop	ffmpeg 프로세스의 CPU 점유율	오디오 변환 등으로 조금 오르는 건 정상

표에서 가장 먼저 해 볼 만한 건 맨 아래 줄입니다. 트랜스코딩 중 ffmpeg 프로세스가 코어 여러 개를 가득 채우고 있다면 소프트웨어 인코딩일 가능성이 큽니다. GPU 도구에 사용률이 잡히고 CPU는 상대적으로 한가해야 정상입니다.

CPU가 완전히 0에 가깝지 않다고 실패한 건 아닙니다. 오디오 변환, 컨테이너 처리, 일부 필터는 가속 중에도 CPU를 씁니다. 판정 기준은 어디까지나 로그의 인코더 이름이고, 이 도구들은 그 판정을 뒷받침하는 용도입니다.

그런데 같은 서버에 같은 설정인데도 영상마다 CPU와 GPU가 갈리는 경우가 있습니다.

로그에 libx264가 찍혔다면, 원인을 좁히는 확인 순서

확인 순서는 장치, 코덱, 옵션, 톤매핑 순입니다. 앞 단계가 해결되기 전에 뒤 단계를 만지면 원인이 섞여서 어디가 문제였는지 알 수 없게 됩니다.

장치가 서버 프로세스에 보이는지

Docker라면 장치와 그룹을 둘 다 넘겨야 합니다. 장치만 넘기고 render 그룹을 빼먹으면 권한 때문에 GPU를 못 엽니다. 호스트에서 ls -l /dev/dri와 getent group render로 그룹 번호를 확인한 뒤 그 값을 넣으세요.

devices:
  - /dev/dri/renderD128:/dev/dri/renderD128
group_add:
  - "122"   # 122는 예시입니다. 내 서버의 render 그룹 번호로 바꾸세요

NVIDIA는 장치 매핑이 아니라 컨테이너 툴킷을 씁니다. 런타임을 nvidia로 두고 환경 변수 NVIDIA_DRIVER_CAPABILITIES=all, NVIDIA_VISIBLE_DEVICES=all을 함께 지정하는 것이 공식 문서의 안내입니다.

이 영상의 코덱을 칩이 풀 수 있는지

하드웨어 디코딩이 되는 코덱은 칩 세대로 갈립니다. 아래는 Jellyfin 공식 문서 기준입니다.

• Intel HEVC 10비트: Kaby Lake(7세대 코어), Apollo Lake·Gemini Lake(펜티엄·셀러론) 이후
• Intel AV1 디코딩: Tiger Lake(11세대 코어) 이후. AV1 인코딩은 DG2(Arc A 시리즈), Meteor Lake 이후
• NVIDIA HEVC 10비트 디코딩: Maxwell 2세대(GM206) 이후
• NVIDIA AV1 디코딩: Ampere 이후. 인코딩은 Ada Lovelace 이후
• GT 1030, MX450 같은 저가·모바일 모델은 NVIDIA인데도 NVENC·NVDEC가 없습니다

양쪽 모두 함정이 있습니다. 설정의 하드웨어 디코딩 목록에서 해당 코덱 체크가 빠져 있으면 그 영상만 소프트웨어 디코딩으로 돌고, 반대로 칩이 못 푸는 코덱을 체크해 두면 그 파일만 실패합니다. 칩 이름을 먼저 정확히 확인하고 목록을 맞추세요.

하드웨어 인코딩 옵션이 빠진 반쪽 가속

로그에 -hwaccel은 있는데 인코더가 libx264라면 디코딩만 GPU입니다. 설정에서 하드웨어 인코딩 옵션(Enable hardware encoding)이 켜져 있는지부터 보세요. 켜져 있는데도 이 모양이라면 해당 출력 코덱의 인코더를 칩이 지원하는지 확인할 차례입니다.

HDR 톤매핑이 걸리는 영상만 느릴 때

HDR을 SDR로 바꾸는 톤매핑은 OpenCL 런타임이 필요합니다. 리눅스에선 수동 설치가 필요한 경우가 있다고 공식 문서가 안내합니다. HDR 영상에서만 유독 느리다면 다음 명령으로 OpenCL이 잡히는지 확인하세요.

sudo /usr/lib/jellyfin-ffmpeg/ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device opencl@va

Intel 저전력 인코더를 켰다면

저전력 인코더 옵션은 GuC·HuC 펌웨어가 로딩돼 있어야 합니다. 커널 옵션 options i915 enable_guc=2를 적용한 뒤 /sys/kernel/debug/dri/0/gt*/uc/ 아래 guc_info, huc_info에서 로딩 상태를 확인할 수 있습니다.

로그는 하드웨어인데 여전히 버벅일 때, speed 값과 병목 후보

ffmpeg 진행 줄의 speed 값이 1.0x 미만이면 재생 속도를 못 따라가는 중이라 버퍼링이 납니다. 하드웨어로 찍혔는데 이 값이 낮다면 GPU 밖 어딘가에서 막히고 있는 겁니다.

(진행 줄 형식 예시)
frame= ... fps= ... q= ... size= ... time= ... bitrate= ... speed=0.8x

점검 순서는 이렇습니다. 걸리는 쪽부터 하나씩 지우세요.

• 트랜스코드 임시 폴더: 대시보드의 트랜스코딩 설정에서 임시 경로를 지정할 수 있습니다. 느린 디스크나 네트워크 드라이브를 가리키면 GPU가 빨라도 쓰기에서 막힙니다.
• 이미지 자막 굽기: PGS 같은 이미지 자막은 영상에 구워 넣어야 해서 트랜스코딩을 강제하는 대표 사례입니다. 자막을 끄거나 텍스트 자막으로 바꾼 뒤 로그를 다시 보세요.
• 오디오 변환: 영상은 그대로 두고 오디오 코덱만 클라이언트가 못 읽어 변환하는 경우가 있습니다. 정보(i) 창의 이유 항목에서 확인됩니다.
• 클라이언트 비트레이트 제한: 앱에서 화질 상한을 낮춰 둔 탓에 Direct Play가 가능한 영상이 굳이 트랜스코딩되는 일도 흔합니다.
• 업로드 대역폭: 외부에서 볼 때는 서버 쪽 업로드가 먼저 막힙니다. 이 경우 speed는 정상인데 클라이언트 버퍼만 비게 됩니다.

저라면 가속 튜닝보다 Direct Play가 되는 조건부터 만듭니다. 트랜스코딩이 아예 걸리지 않으면 어떤 하드웨어든 변수가 사라지기 때문입니다.

💡 내 로그가 이 모양이면? 간단 시뮬레이션

-hwaccel 있음 + 인코더 h264_qsv(또는 nvenc·vaapi) → 완전 가속입니다. 끊긴다면 speed 값과 위 병목 후보를 보세요.
-hwaccel 있음 + 인코더 libx264 → 반쪽 가속입니다. 하드웨어 인코딩 옵션과 인코더 지원 여부를 확인하세요.
-hwaccel 없음 + 인코더 h264_nvenc 등 하드웨어 인코더 → 인코딩만 GPU입니다. 해당 코덱이 하드웨어 디코딩 목록에서 빠졌거나 칩이 못 푸는 코덱일 수 있습니다.
-hwaccel 없음 + 인코더 libx264 → 전부 CPU입니다. 장치 접근부터 확인하세요.

같은 영상인데 인코더 한 줄이 달라지면 결과가 완전히 갈립니다.

젤리핀 하드웨어 가속 확인 자주 묻는 질문

Q. 설정에서 QSV를 골랐는데 로그에는 libx264만 보여요. 어디부터 봐야 하나요?

장치, 코덱, 옵션, 톤매핑 순서로 보세요. 컨테이너 안에서 vainfo가 에러 없이 프로파일을 보여 주는지 확인하고, 그다음 그 영상의 코덱이 하드웨어 디코딩 목록에 체크돼 있는지, 하드웨어 인코딩 옵션이 켜져 있는지 순으로 내려가면 됩니다.

Q. 로그에는 h264_nvenc라고 나오는데 nvidia-smi에는 아무것도 안 보여요.

Docker 환경에서는 프로세스 목록이 비어 보이는 경우가 있습니다. 로그의 인코더 이름이 판정 기준이고, 교차 확인이 필요하면 nvidia-smi dmon -s u의 enc·dec 사용률이 재생 중에 올라가는지 보세요.

Q. 트랜스코딩 중에 CPU도 같이 올라가는데 가속이 실패한 건가요?

그렇지 않습니다. 오디오 변환, 컨테이너 처리, 일부 필터는 가속 중에도 CPU를 씁니다. 로그의 인코더가 하드웨어 이름이고 ffmpeg 프로세스가 코어 여러 개를 채우는 수준이 아니라면 가속은 된 겁니다.

Q. 4K HEVC HDR 영상만 버벅이고 1080p는 멀쩡해요.

세 가지가 겹칩니다. 칩이 HEVC 10비트를 하드웨어로 푸는 세대인지, HDR을 SDR로 바꾸는 톤매핑(OpenCL)이 잡히는지, 원본 비트레이트가 서버 디스크·네트워크 한계를 넘는지입니다. 로그에서 필터 체인에 tonemap 계열 이름과 hwdownload가 있는지 먼저 보세요.

Q. FFmpeg.Transcode 로그 파일이 너무 많아서 어느 게 내 재생인지 모르겠어요.

재생을 시작한 직후에 가장 최신 파일을 여세요. 파일명에 시각이 들어 있고, 재생 중에는 파일이 계속 커집니다. 영상을 바꿔 가며 확인할 때는 바꿀 때마다 새 파일이 생기는지 보면 구분됩니다.

마무리, 지금 로그에서 확인할 3가지

①재생을 시작하고 최신 FFmpeg.Transcode 로그를 열어 -hwaccel과 인코더 이름을 확인하세요. ②호스트 도구(intel_gpu_top, nvidia-smi, top)로 부하가 실제로 어디에 걸리는지 교차하세요. ③하드웨어로 찍혔는데도 끊기면 speed 값이 1.0x 아래인지 보고 임시 폴더, 자막, 오디오, 비트레이트 순으로 지워 나가세요.

가속 설정 화면을 처음부터 맞추는 순서는 젤리핀 설치부터 하드웨어 가속·퀵커넥트 설정까지 순서대로 정리한 글에 따로 있습니다. 이 글은 그 설정을 마친 뒤 실제로 켜졌는지 검증하는 쪽만 다뤘습니다.