홈 서버에서 Jellyfin이 버퍼링되는 이유는 무엇인가요?

Jellyfin은 재생 경로의 한 부분이 타임라인 진행 속도보다 비디오를 더 빠르게 전달, 변환 또는 디코딩하지 못할 때 버퍼링합니다. 비디오 트랜스코딩이 흔한 원인이지만 유일한 원인은 아닙니다. 스트림은 클라이언트 코덱 제한, 자막 처리, 불안정한 Wi-Fi, 부족한 원격 업로드 대역폭, 저장소 경쟁, 또는 임시 데이터를 더 이상 받을 수 없는 트랜스코드 디렉터리 때문에도 멈출 수 있습니다.

병목 현상을 가장 빠르게 찾는 방법은 하드웨어 설정을 변경하기 전에 현재 재생 모드를 확인하는 것입니다. 그런 다음 문제가 모든 파일에 영향을 미치는지, 4K 또는 HDR 미디어에만 국한되는지, 특정 클라이언트, 원격 사용자, 자막 활성화 재생, 또는 여러 동시 스트림에 영향을 미치는지 비교하세요.

무엇이든 변경하기 전에 재생 모드를 확인하세요

영향받는 비디오가 재생되는 동안 Jellyfin 대시보드를 열어 활성 세션을 확인하세요. 이를 통해 서버가 원본 파일을 전달하는지 아니면 일부를 적극적으로 변환 중인지 알 수 있습니다.

Jellyfin은 재생을 서버 부하가 점진적으로 증가하는 네 가지 재생 경로로 구분합니다: Direct Play, Remux, Direct Stream, 비디오 트랜스코드. Direct Play는 거의 처리 없이 원본 미디어를 전송합니다. Remux는 컨테이너를 변경하고, Direct Stream은 비디오는 유지하면서 오디오를 변환하며, Transcode는 비디오 스트림을 재인코딩합니다.

이 첫 번째 결과가 전체 문제 해결 방향을 바꿉니다. Direct Play가 버퍼링된다면 네트워크, 저장소, 클라이언트, 미디어 파일부터 점검하세요. 비디오 트랜스코딩이 버퍼링된다면 변환 요청 이유와 서버가 전체 파이프라인을 충분히 빠르게 완료할 수 있는지 확인하세요.

Jellyfin이 트랜스코딩을 요청한 이유 알아보기

클라이언트가 비디오 코덱을 지원한다고 해서 파일이 자동으로 Direct Play되는 것은 아닙니다. Jellyfin은 컨테이너, 비디오 코덱, 코덱 프로필, 비트 깊이, 해상도, 오디오 형식, 채널 구성, 자막, 비트레이트, 클라이언트 재생 제약 조건의 전체 조합을 평가합니다.

예를 들어, 클라이언트는 HEVC 비디오는 지원하지만 포함된 TrueHD 오디오 트랙은 지원하지 않을 수 있습니다. 다른 클라이언트는 두 스트림을 모두 디코딩하지만 선택한 자막 형식을 렌더링하지 못할 수 있습니다. 이러한 차이로 인해 동일한 파일이 한 기기에서는 다이렉트 플레이, 다른 기기에서는 오디오 변환, 브라우저에서는 전체 비디오 트랜스코딩으로 처리될 수 있습니다.

설정을 변경하기 전에 재생 이유를 기록하세요. 또한 다른 오디오 트랙을 테스트하고 자막을 비활성화하며 다른 Jellyfin 클라이언트로 동일한 파일을 재생해 보세요. 이러한 통제된 테스트가 트랜스코딩 메뉴에서 모든 코덱 박스를 활성화하는 것보다 더 유용합니다.

소프트웨어 트랜스코딩은 작은 서버에 과부하를 줄 수 있습니다

소프트웨어 트랜스코딩은 CPU를 사용해 소스를 디코딩하고 필터를 적용하며 이미지를 스케일링하고 실시간으로 새 스트림을 인코딩합니다. 저성능 프로세서는 1080p 변환은 처리할 수 있지만, 소스가 4K HEVC, 10비트 비디오 또는 HDR일 경우 실패할 수 있습니다.

변환이 재생 속도를 따라가지 못하면 클라이언트는 결국 버퍼링된 비디오 세그먼트를 모두 소비하고 일시 정지합니다. Jellyfin이 현재 위치보다 충분한 데이터를 계속 생성하려 시도하는 동안 CPU 사용량은 최대치에 가까울 수 있습니다.

서버에 지원되는 통합 또는 독립 GPU가 있고 하드웨어 가속이 올바르게 구성되어 있다면, FFmpeg 스레드 수를 변경하는 것보다 보통 더 유용합니다. 호환 인코더가 없는 경우 요청한 해상도나 비트레이트를 줄여 트랜스코딩 용량이 제한 요인인지 확인할 수 있습니다.

하드웨어 가속은 다단계 파이프라인입니다

대시보드에서 Intel Quick Sync, VA-API, NVIDIA NVENC 또는 AMD AMF를 선택해도 변환의 모든 부분이 GPU에서 실행된다는 보장은 없습니다.

Jellyfin 트랜스코드는 디코딩, 디인터레이싱, 스케일링, 형식 변환, HDR 톤 매핑, 자막 번인, 인코딩을 포함할 수 있습니다. Jellyfin은 하드웨어, 드라이버 또는 소프트웨어 제한으로 인해 일부 단계가 CPU에서 실행될 수 있다고 명시합니다. 부분 가속은 GPU 활동이 보이더라도 높은 CPU 사용량을 초래할 수 있습니다.

GPU 존재 여부만 확인하지 말고 전체 작업을 검증하세요. 예측 가능한 트랜스코드를 강제로 실행하고, 비디오 디코드 및 인코드 엔진을 관찰하며, FFmpeg 명령어를 검사하고 소프트웨어로 대체된 필터가 있는지 확인하세요.

GPU가 처리할 수 없는 디코드 형식은 활성화하지 마세요

하드웨어 가속 페이지에서는 관리자가 Jellyfin이 GPU를 통해 디코딩을 시도할 수 있는 비디오 포맷을 선택할 수 있습니다. 지원하지 않는 포맷을 활성화해도 하드웨어 기능이 추가되지는 않습니다.

GPU가 정확한 코덱 프로필이나 비트 깊이를 디코딩할 수 없으면 Jellyfin은 소프트웨어 디코딩으로 대체하거나 하드웨어 경로 초기화에 실패할 수 있습니다. 이 때문에 한 HEVC 파일은 작동하지만 다른 파일은 예상치 못한 높은 CPU 사용량을 유발할 수 있습니다.

GPU 세대와 지원 프로필을 확인한 후 실제로 처리할 수 있는 포맷만 활성화하세요. 모든 4K 미디어를 하나의 작업으로 처리하지 말고 일반 H.264, HEVC Main 10, HDR 파일을 별도로 테스트하세요. 4k-home-media-server

Docker에 GPU 접근 권한 부여 필요

호스트 운영체제에서 감지된 GPU가 자동으로 Jellyfin 컨테이너 내에서 사용 가능한 것은 아닙니다. 컨테이너는 올바른 장치 매핑, 런타임, 드라이버, 그룹 및 권한도 필요합니다.

Linux에서 Intel 및 AMD GPU의 경우 호스트는 일반적으로 /dev/dri 아래에 렌더 장치를 노출합니다. 컨테이너 사용자는 관련 렌더 장치에 접근할 수 있어야 합니다. NVIDIA 구성은 호스트 드라이버와 적절한 컨테이너 런타임이 필요합니다. 실용적인 Docker 점검에는 렌더 장치 확인, 컨테이너로 매핑, 올바른 렌더 그룹 GID 추가가 포함됩니다.

컨테이너를 영구적으로 권한 모드로 두지 마세요. 이는 근본적인 문제인 장치 접근 권한을 확인하는 데 잠시 사용할 수 있지만, 최종 배포 시에는 필요한 GPU 리소스와 권한만 노출해야 합니다.

실제 트랜스코딩 중 GPU 활동 확인

컨테이너가 성공적으로 시작되었다고 해서 하드웨어 트랜스코딩이 작동한다는 증거는 아닙니다. Jellyfin은 정상적으로 실행되고 라이브러리를 스캔하며 Direct Play 파일을 재생할 수 있지만 GPU에 사용할 수 있는 접근 권한이 없을 수 있습니다.

소스보다 낮은 클라이언트 품질을 일시적으로 선택하여 트랜스코딩을 강제로 실행하세요. Intel 시스템에서는 다음과 같은 도구로 비디오 엔진을 모니터링하세요. intel_gpu_topNVIDIA 시스템에서는 활성 프로세스와 인코더 활동을 다음을 통해 검사하세요. nvidia-smi또한 소프트웨어 트랜스코딩과 비교하여 CPU 사용량이 감소하는지 확인하세요.

GPU 활동이 없으면 매핑된 장치, 컨테이너 사용자, 렌더 그룹 멤버십, 하드웨어 가속 방식 및 FFmpeg 로그를 확인하세요. GPU가 활성화되어 있지만 재생이 느리다면 다른 파이프라인 단계가 여전히 소프트웨어에서 실행 중일 수 있습니다.

자막은 전체 비디오 트랜스코딩을 유발할 수 있습니다

일반적인 증상은 자막이 활성화될 때까지는 부드러운 재생이지만, 이미지 기반 자막이나 선택한 클라이언트가 직접 렌더링할 수 없는 스타일 자막 형식에서 자주 발생합니다.

Jellyfin이 자막을 이미지에 번역해야 할 때, 모든 프레임을 디코딩하고 자막 레이어를 렌더링하며 새 비디오 스트림을 인코딩합니다. 이는 그렇지 않으면 부하가 낮은 Direct Play 세션을 서버에서 가장 비용이 많이 드는 재생 경로 중 하나로 만들 수 있습니다.

자막을 비활성화하고 같은 장면을 다시 재생하세요. 버퍼링이 사라지면 SRT 같은 텍스트 기반 자막 트랙을 시도하거나 다른 클라이언트를 테스트하거나 선택한 하드웨어 경로가 주변 디코딩, 필터링 및 인코딩 작업을 가속할 수 있는지 확인하세요.

HDR 톤 매핑은 일반 트랜스코딩보다 더 많은 자원을 요구할 수 있습니다

1080p 및 일반 4K SDR 미디어는 정상 재생되지만 HDR 콘텐츠가 SDR 클라이언트에서 버퍼링된다면, 톤 매핑이 유력한 원인입니다.

서버는 10비트 HDR 소스를 디코딩하고, 색상 및 밝기 범위를 SDR로 변환하며, 크기를 조정하고, 새 비디오 스트림을 인코딩해야 할 수 있습니다. 일반 H.264 트랜스코딩이 가능한 시스템도 소프트웨어를 통해 이 전체 작업을 실시간으로 수행하지 못할 수 있습니다.

같은 HDR 파일을 HDR 지원 클라이언트에서 테스트한 후 SDR 트랜스코딩을 강제로 실행하고 CPU 및 GPU 활동을 비교하세요. HEVC 디코딩에 대한 하드웨어 지원이 선택된 톤 매핑 방식이 완전히 가속화됨을 자동으로 증명하지는 않습니다.

클라이언트가 재생 경로의 많은 부분을 결정합니다

Jellyfin은 데스크톱 미디어 클라이언트에서는 파일을 Direct Play할 수 있지만, 브라우저나 TV 애플리케이션에서는 트랜스코딩할 수 있습니다. 이 차이가 세션 간 서버 구성이 변경되었음을 의미하지는 않습니다.

각 클라이언트는 지원하는 코덱, 컨테이너, 오디오 형식, 자막, 해상도 및 비트레이트 제한을 보고합니다. 더 강력한 플레이어는 변환을 피할 수 있지만, 제한된 플레이어는 오디오 변환, 리멕싱 또는 완전한 비디오 트랜스코딩이 필요할 수 있습니다.

같은 파일, 오디오 트랙, 자막 트랙, 네트워크 연결을 두 클라이언트에서 테스트하세요. 문제가 특정 클라이언트에만 발생한다면, 서버를 수정하기 전에 해당 장치의 재생 기능과 앱 설정을 조사하세요.

Direct Play도 버퍼링이 발생할 수 있습니다

Direct Play는 비디오 변환을 주요 병목 현상에서 제거하지만, 경로의 다른 모든 부분이 정상임을 증명하지는 않습니다.

NAS는 여전히 미디어를 읽어야 하고, 네트워크는 이를 지속적으로 전달해야 하며, 클라이언트는 이를 디코딩하고 렌더링해야 합니다. 높은 비트레이트 피크, 불안정한 Wi-Fi, 느린 클라이언트 인터페이스, 저장소 오류 재시도 또는 성능이 부족한 플레이어는 그렇지 않으면 직접 스트림을 방해할 수 있습니다.

문제가 있는 파일을 클라이언트에 복사해 로컬에서 재생하세요. 로컬 재생도 끊기면 미디어 파일이나 클라이언트 디코더를 조사하세요. 로컬 복사는 정상인데 Jellyfin 다이렉트 플레이가 버퍼링된다면 네트워크와 서버 저장 경로에 집중하세요.

인터넷 속도 테스트 대신 실제 LAN 경로를 테스트하세요

빠른 인터넷 속도 결과는 Jellyfin 서버에서 집 안의 TV, 휴대폰, 스트리밍 박스까지의 경로를 측정하지 않습니다. 또한 Wi-Fi 지터, 패킷 손실, 메시 백홀 혼잡, 느린 장치 인터페이스도 드러내지 않습니다.

유용한 로컬 진단은 지속적인 파일 복사 처리량, 유선 클라이언트, 낮은 비트레이트 인코딩, 그리고 원본 고비트레이트 파일을 비교하는 것입니다. 실용적인 로컬 스트리밍 점검에는 이더넷 테스트, 클라이언트가 트랜스코딩을 강제하는지 확인, 시청 시간 외에 무거운 백그라운드 작업 이동도 포함됩니다.

몇 초 동안 표시되는 최고 수치보다는 지속적인 성능을 확인하세요. 비트레이트가 큰 영상은 짧은 네트워크 지연에도 클라이언트 버퍼를 소진하지 않고 견딜 수 있는 충분한 여유가 필요합니다.

원격 버퍼링은 보통 다른 원인이 있습니다

같은 미디어가 집에서는 제대로 재생되지만 외부 연결에서는 버퍼링된다면, 서버 업로드 대역폭과 원격 경로가 주요 의심 대상입니다.

사용 가능한 속도는 가정용 연결의 업로드 속도, 원격 클라이언트의 다운로드 속도, VPN 또는 리버스 프록시 오버헤드, 경쟁하는 가정 내 트래픽, 그리고 스트림 비트레이트에 의해 제한됩니다. 큰 리멕스는 LAN에서 완벽하게 다이렉트 플레이되더라도 사용 가능한 업로드 용량을 초과할 수 있습니다.

원격 재생 품질을 일시적으로 낮추세요. 버퍼링이 해결되면 지속 가능한 원격 비트레이트를 설정하거나 하드웨어 트랜스코딩을 사용해 더 작은 스트림을 만드세요. 낮은 설정을 대역폭 한계의 증거로 간주하고 원본 파일이 손상되었다는 증거로 보지 마세요.

동시 작업 시 저장 장치 고장 가능성이 더 높습니다

건강한 하드 드라이브는 보통 하나의 일반 영화 스트림을 문제없이 읽을 수 있습니다. 재생이 다운로드, 백업, 라이브러리 스캔, 썸네일 생성, 패리티 작업, 스크럽, 또는 여러 사용자와 겹칠 때 저장 장치는 더 의심스러워집니다.

이 작업들은 읽기, 쓰기, 탐색 작업이 서로 경쟁하게 만듭니다. 디스크는 벤치마크에서 허용 가능한 순차 속도를 보여줄 수 있지만, 혼합된 활동 중에는 높은 지연 시간을 발생시킬 수 있습니다.

버퍼링이 발생하는 동안 사용률과 지연 시간을 모니터링하세요. 다운로드와 유지보수 작업을 일시 중지한 후 동일한 파일을 다시 재생해 보세요. Jellyfin 데이터베이스, 메타데이터, 캐시는 가능한 낮은 지연 시간의 저장소에 두고, 대용량 미디어 파일은 용량 중심 디스크에 유지하는 것이 좋습니다.

가득 찬 트랜스코딩 디렉터리는 재생을 중단시킬 수 있습니다

트랜스코딩된 비디오는 클라이언트가 소비하기 전에 임시 세그먼트로 기록됩니다. 할당된 파일 시스템, SSD, RAM 디스크 또는 Docker 볼륨에 충분한 여유 공간이 없으면 FFmpeg가 새 세그먼트를 생성할 수 없습니다.

이전 Jellyfin 이슈에서는 트랜스코딩 디렉터리가 가득 차기 전 마지막 세그먼트까지만 재생이 가능했다는 사례가 문서화되었습니다. 이 보고서는 오래되고 종료되었지만, 트랜스코딩된 스트림이 몇 분 후 중단될 때 공간을 점검해야 하는 유용한 증상입니다.

트랜스코딩 경로의 여유 공간, 아이노드 가용성, 컨테이너 매핑, 쓰기 권한, 용량 제한을 확인하세요. 특히 작은 RAM 디스크나 임시 파일 시스템을 사용할 때 주의하세요. 메모리 사용은 저장 지연 시간을 줄일 수 있지만, 제한이 너무 작으면 갑작스러운 재생 실패를 초래할 수 있습니다.

하나의 문제 파일은 보통 미디어 문제를 가리킵니다

해상도와 비트레이트가 비슷한 여러 파일이 정상 재생된다면, 단일 실패 타이틀이 서버 전체가 부족하다는 증거가 될 가능성은 낮습니다.

파일에 특이한 코덱 프로필, 손상된 프레임, 지원되지 않는 오디오 레이아웃, 이미지 자막 트랙, 잘못된 타임스탬프 또는 극단적인 비트레이트 피크가 포함될 수 있습니다. 한 시즌의 쇼가 다른 시즌과 다르게 인코딩되었을 수도 있습니다.

다른 오디오 트랙을 테스트하고, 자막을 비활성화하며, 미디어 정보를 확인하고, 동일한 코덱을 사용하는 다른 타이틀과 파일을 비교하세요. 전체 비디오를 재인코딩하지 않고도 컨테이너나 타임스탬프 문제인지 확인하려면 새 컨테이너로 간단히 리멕스(remux)하는 것이 도움이 됩니다.

여러 스트림은 공유 자원 한계를 드러냅니다

홈 서버는 한 스트림을 완벽하게 처리할 수 있으며, 다른 사용자가 재생을 시작할 때만 버퍼링이 발생할 수 있습니다. 네트워크만 문제라고 가정하기 전에 모든 활성 세션의 재생 모드를 비교하세요.

여러 개의 Direct Play 세션은 주로 저장 공간과 네트워크 부하를 증가시킵니다. 여러 비디오 트랜스코딩도 GPU 인코딩 용량, CPU 필터, 메모리 대역폭, 트랜스코딩 디렉터리 공간을 경쟁합니다.

한 세션을 테스트한 후 CPU, GPU, 디스크 및 네트워크 사용량을 관찰하면서 스트림을 하나씩 추가하세요. 이를 통해 실제 한계가 변환 수인지, 총 미디어 비트레이트인지, 아니면 혼합 저장소 활동인지 식별할 수 있습니다.

Jellyfin을 재설치하기 전에 FFmpeg 로그를 읽으세요.

서버 대시보드는 어떤 유형의 재생이 발생하는지 알려주며, 해당 FFmpeg 로그는 Jellyfin이 파일을 처리하려고 시도한 방법을 설명합니다.

하드웨어 장치 초기화 실패, 권한 오류, 지원되지 않는 프로필, 소프트웨어 폴백, 자막 필터, 톤 매핑 필터, 입출력 오류, 프로세스 종료 코드 및 저장 공간 오류를 확인하세요.

버퍼링하는 정확한 세션의 로그를 캡처하세요. 관련 없는 직접 재생 또는 성공적인 트랜스코드 로그는 잘못된 결론을 초래할 수 있습니다. 서버를 재설치해도 클라이언트 코덱 제한, 접근 불가능한 GPU 장치 또는 가득 찬 임시 디렉터리는 거의 해결되지 않습니다.

증상을 사용하여 다음 테스트를 선택하세요.

이 문제 해결 순서를 따르세요.

1. 동일한 파일과 클라이언트로 문제를 재현하세요.
2. Jellyfin 대시보드를 열고 재생 모드를 기록하세요.
3. 명시된 트랜스코드 또는 호환성 이유를 기록하세요.
4. 자막을 비활성화하고 다른 오디오 트랙을 테스트하세요.
5. 다른 클라이언트에서 동일한 파일을 재생하세요.
6. 영향을 받은 세션 동안 CPU 및 GPU 활동을 확인하세요.
7. 일치하는 FFmpeg 로그를 여세요.
8. 트랜스코드 디렉터리 공간과 쓰기 권한을 확인하세요.
9. 지속적인 LAN 처리량 또는 원격 업로드 용량을 테스트하세요.
10. 다운로드, 백업, 스캔 및 저장소 유지 관리를 일시 중지하세요.
11. 문제 파일을 유사한 미디어와 비교하세요.
12. 증거가 계산 한계를 보여줄 때만 새 하드웨어를 고려하세요.

이 순서는 관련 없는 변경 사항이 원인을 숨기지 않도록 합니다. 한 번에 하나의 변수를 변경하고 동일한 장면을 재생하여 결과를 비교 가능하게 유지하세요.

최종 요약

Jellyfin 버퍼링이 자동으로 홈 서버에 더 빠른 CPU가 필요하다는 의미는 아닙니다. 활성 재생 모드부터 시작하세요. Direct Play와 비디오 트랜스코딩은 시스템의 다른 부분을 가리킵니다.

트랜스코딩 세션의 경우 변환이 필요한 이유를 파악하고, 완전한 하드웨어 가속 파이프라인을 검증하며, 자막 없이 테스트하고, HDR 톤 매핑을 검사하고, 트랜스코드 경로에 충분한 쓰기 가능한 공간이 있는지 확인하세요. Docker에서는 호스트 감지에만 의존하지 말고 컨테이너 내부에서 GPU를 확인하세요.

Direct Play의 경우 지속적인 네트워크 처리량, 클라이언트 디코딩, 저장소 활동 및 개별 미디어 파일에 집중하세요. 재생 모드, 클라이언트, 코덱, 자막, 리소스 활동 및 FFmpeg 로그의 조합이 무작위 설정 변경이나 하드웨어 교체보다 더 신뢰할 수 있는 진단을 제공합니다.

자주 묻는 질문(FAQ)

왜 자막이 활성화된 경우에만 Jellyfin이 버퍼링하나요?

선택한 자막 형식은 번인(burn-in)이 필요할 수 있습니다. 이 경우 Jellyfin은 비디오를 디코딩하고, 자막을 모든 프레임에 렌더링한 후 새 스트림을 인코딩해야 합니다. 자막을 비활성화하거나 텍스트 기반 트랙을 선택하거나 자막 형식을 직접 렌더링할 수 있는 클라이언트를 사용해 보세요.

왜 Jellyfin은 한 장치에서는 트랜스코딩하고 다른 장치에서는 Direct Play를 하나요?

클라이언트는 다양한 컨테이너, 비디오 코덱, 오디오 형식, 자막 유형, 프로필 및 비트레이트 조합을 지원합니다. 호환성이 낮은 장치는 서버에 파일의 지원되지 않는 부분을 변환하도록 요청합니다.

Jellyfin 하드웨어 가속이 작동하는지 어떻게 확인하나요?

비디오 트랜스코딩을 강제로 실행한 후 서버의 GPU 디코드 및 인코드 엔진을 확인하세요. 또한 FFmpeg 로그가 예상된 하드웨어 장치를 사용하고 있는지, 컨테이너가 권한 오류 없이 장치에 접근할 수 있는지도 확인하세요.

Jellyfin이 Direct Play라고 표시되는데도 왜 버퍼링하나요?

Direct Play는 비디오 트랜스코딩을 경로에서 제거하지만, 네트워크, 저장소, 미디어 파일 및 클라이언트 디코더가 여전히 너무 느리거나 불안정할 수 있습니다. 동일한 클라이언트에서 파일을 로컬로 테스트하고 유선과 무선 재생을 비교하세요.

Jellyfin이 트랜스코딩에 SSD를 사용해야 하나요?

SSD는 임시 세그먼트 지연 시간을 줄일 수 있으며 Jellyfin 데이터베이스, 메타데이터 및 캐시에 유용합니다. 더 중요한 요구 사항은 충분한 공간, 안정적인 쓰기 및 올바른 권한을 갖춘 트랜스코드 경로입니다. 적절한 크기의 RAM 디스크도 작동할 수 있지만, 크기가 너무 작으면 재생이 중단될 수 있습니다.